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'I  ABSTRACT 

If 

The  develoomeot  and  i mol enent at  1 on  of  refresh  graphics 
software  for  the  Vector  General  Display  System  on  a PDP-11 
minicomputer  is  discussed.  Modification  and  expansion  of 
existing  software  routines*  along  with  additional  software 
design  and  development  is  pr.esented.  As  an  addition  to  the 
i existing  C programming  langu'age*  a version  of  BASIC  was 

implemented  as  a second  language  capable  of  utilizing  the 
Vector  General  software.  The  unsuccessful  implementation  of 
a version  of  FORTRAN  with  the  display  system  software  and 
the  problems  involved  are  discussed.  Conclusions  and 
recommendations  are  offered*  and  a detailed  user’s  manual  is 
^ appended. 
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I.  INTRODUCTION 


The  Vector*  Ger^eral  Graohics  Dis'olay  Unit  in  conjunction 
with  the  POP-11/50  minicomputer  provides  the  Naval 
Postgraduate  School  Computer  Laboratory  with  a sophisticated 
three-dimensional  graphics  display  system.  Hardware 
facilities  provide  for  three-dimensional  rotation, 
translation,  and  scaling  of  graohics  data.  Deoth>cueing  is 
accomplished  by  varying  object  intensity.  A circle/arc 
generator,  in  addition  to  a vector  and  character  generator, 
further  enhances  the  system  by  allowing  the  user  to  draw 
arcs  and  circles  with  specification  of  only  two  or  three 
points.  Additionally,  external  devices  in  the  form  of  an 
alphanumeric  keyboard,  lighted  function  switches,  control 
dials,  trackball#  joystick,  and  lightoen  provide  interactive 
control  of  the  display  presentation. 

Integral  to  the  operation  of  the  Vector  General  Is  the 
display  controller.  The  display  controller  is  a processor 
which  receives  data  from  a display  list,  decodes  the  data 
into  graphic  commands,  and  activates  the  appropriate 
generator  to  output  the  desired  information.  The 
construction  and  maintenance  of  the  display  list  is 
accomplished  through  the  use  of  the  Vector  General  Graohics 
Library.  The  library  functions  as  the  interface  between  the 
user  and  display  controller.  Simple  primitives  are  provided 
allowing  the  user  to  build  the  display  list.  Additionally, 


th«  software  allows  the  disolay  controller  to  communicate  to 


* 

*■' 


the  user  information  obtained  from  external  devices  which 
may  be  used  to  orogramat ical I y control  the  display 
presentat ion. 

Previous  thesis  work  by  Thorpe  till  (12] > Visco  (151 » 
and  Stankowski  (10)  provided  fundamental  graphics  software 
and  should  be  consulted  for  original  design  considerations. 
The  objective  of  work  described  in  this  thesis  was  to 
review,  modify,  and  extend  orevious  work  to  provide  more 
useable  graphics  software  for  the'Vector  General  Display 
System.  To  this  extent  certain  goals  were  set.  All 
previous  work  was  to  be  reviewed,  revised  and  updated.  A 
significant  portion  of  time  was  to  be  spent  in  testing  and 
debugging  previously  untested  routines.  The  design  and 
implementation  of  software  to  supoort  the  trackball, 
joystick.  and  lightpen  facilities  was  to  be  undertaken. 
Extension  of  existing  routines  to  simplify  their  apolication 
had  to  be  accomplished.  Expansion  of  application  languages 
which  supeort  vector  graphics  to  include  BASIC  and  FORTRAN 
was  seen  as  a most  significant  goal  of  the  research.  The 
culmination  of  the  study  was  seen  to  be  the  compilation, 
testing,  and  evaluation  of  all  existing  and  newly  generated 
software,  and  the  incorporation  of  all  relevant  information 
into  one  user«or i ented  reference  manual. 
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II.  BACKGROUND 


A«  most  of  the  Mork  discussed  in  this  thesis  concerns 
modi f i cet i ons  and  extensions  to  orevious  thesis  workr  a 
description  of  prior  work  is,  in  order.  Thorpe  and  Raetz 
[tl]  [12]  designed  the  original  data  structures  for 
constructing  and  maintaining  the  display  list.  The  display 
list  was  constructed  by  a series  of  subroutine  calls  which 
produced  the  correct  seouence  of  graphic  commands  resulting 
in  a picture  generation. 

The  display  was  constructed  on  three  hierarchical 
levels:  picture#  object#  and  element.  An  element  is  the 
smallest  picture  segment  that  can  be  referenced.  It 
consists  of  a seouence  of  move#  line#  arc#  circle#  and 
character  commands.  An  element  must  be  associated  with  an 
object  before  it  can  be  displayed  and  an  object  may  comprise 
a maximum  of  10  elements.  A picture  refers  to  all  the  data 
displayed  on  the  screen  and  may  consist  of  up  to  10  objects. 

Visco  IISJ  was  concerned  with  the  design  of  a multi- 
processor system  to  support  real-time  interactive  graphics. 
Due  to  the  high  priority  of  direct  memory  access  (DHA) 
reguests  necessary  to  support  refresh  graphics#  the  multi- 
processor configuration  was  envisioned  as  a solution  to  the 
DMA  bus  tie-up  problem.  Previous  work  done  by  Thorpe  and 
Raetz  was  modified  by  Visco  to  conform  to  the  envisioned 
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system 


Stanlf^OMsk  1 [101  expanded  upon  previous  work  bv  allowinq 

the  user  to  construct  elements  and  objects  with  alphanumeric 
names  replacing  the  previous  numbering  convention.  The 
object  "TREE"  could  now  contain  elements  "branchl"  through 
"branchlO".  Additionally#  Stankowski  designed  a number  of 
routines  for  the  user  to  more  easily  construct  a display 
list. 

I 

O'Dell  [51  accomplished  the  implementation  of  a ! 

segmented-process  memory  management  UNIX  operating  system 
that  had  been  previously  designed  by  Emery  [31. 

Additionally#  design  and  implementation  was  done  in  a dual- 
ported  memory  environment  where  designated  portions  of  core 
were  sharable  regions.  O'Dell's  work  helped  lay  the 
groundwork  for  a more  general i2ed  system  in  which  additional 
languages  could  support  graphics  programs. 

Previous  paragraphs  have  presented  work  completed  prior 
to  the  commencement  of  research  reported  in  this  thesis. 

The  adeguacy  of  the  interface  between  the  user  and  Vector 
General  was  still  in  doubt.  Software  for  the  trackball# 
joystick#  and  lightoen  facilities  was  missing  and  routines 
for  other  external  devices  were  not  readily  useable. 

Although  routines  were  present  to  construct  and  maintain  the 
display  list#  the  majority  of  them  had  not  been  tested. 

Compatabi 1 i ty  with  O'Dell's  SSUNIX  and  expansion  of 


nr.  LANGUAGE  EXPANSION 


A.  GENERAL 

In  reviewing  the  Vector  General  Display  Systee  and  the 
Naval  Postgraduate  School  Graphics  Laboratory,  it  was  noted 
that  most  of  the  software  was  written  in  C programming 
language.  This  circumstance  demanded  that  any  further 
language  introduction  would  reouire  compatab i 1 i ty  with  C and 
the  UNIX  POP-ll  operating  system.  Two  languages  became  the 
focus  of  attention  due  mainly  to  their  wide  use  and  apparent 
ability'  to  call  C subroutines.  Versions  of  BASIC  and 
FORTRAN  were  chosen  as  the  languages  to  attempt 
implementation  with  the  Vector  General  software.  As  work 
progressed  on  these  languages*  strengths  and  weaknesses  were 
noted  for  both  that  could  effect  further  development  and  use 
throughout  the  Graphics  Laboratory.  The  following  two 
sections  will  explore  each  language*  their  origins  and 
difficulties  in  development*  and  implementation. 

B.  BASIC 

1.  Background 

In  previous  work*  Robertson  (91  implemented  an  Extended 
BASIC  compiler.  BASIC  (Beginner's  Al1«purpose  Symbolic 
Instruction  Code)  was  originally  developed  at  Dartmouth 
College  and  has  undergone  many  changes  to  suit  user  needs. 

\2 


The  extensions  i mol emented  by  Robertson  include  such  items 
as  string  manipulation*  sequential  access  to  external  files* 
mu  1 1 i 'di mensi one  I arrays*  logical  operators  for  numeric  and 
string  quantities*  and  the  ability  to  call  C subroutines. 

The  Extended  BASIC  compiler*  hereafter  referred  to  as 
simply  BASIC*  is  not  a ourely  interpretive  compiler.  It 
generates  an  intermediate  code  (POP-1 1 assembly  language) 
from  the  BASIC  source  program.  BASIC  object  modules  and  C 
subroutine  object  modules  are  able  to  be  linked  together. 
One  final  link  and  load  operation  provides  the  ultimate 
interface  between  the  two  different  language  modules. 

The  first  step  in  understanding  BASIC  was  to  follow  the 
operation  of  the  shell  command  which  controls  the 
compilation*  assembly*  and  linking.  This  shell  command* 
LBAX*  is  a user-accessible  executable  command  on  the  Naval 
Postgraduate  School's  UNIX  POP-1 1 file  system.  The  command 
goes  through  three  phases  of  operation*  all  of  which  depend 
on  the  option  codes  included  (switches  set)  when  the  command 
is  issued.  The  first  phase  is  the  compile  phase.  This 
phase  compiles  the  BASIC  program  source  code  and  emits  a 
PDP-ll  assembly  language  file  as  the  output.  The  second 
phase  causes  the  assembly  of  this  assembly  language  file 
using  the  UNIX  assembler  command  "as”.  This  assembly  emits 
an  "a.out"  file  for  use  in  a final  linking  and  loading 
phase.  The  final  phase  uses  the  UNIX  system  loader  command* 
"Id**  to  link  and  load  all  necessary  object  modules.  The 
LBAX  shell  command  automatically  loads  the  respective  BASIC 
and  C libraries  to  reconcile  all  undefined  references.  The 
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output  of  this  final  link  and  load  Phase  is  an  eaecutable 
"a. out"  file.  Within  this  final  stage  of  the  LB*X  command, 
an  option  is  invoked  to  regulate  the  UNIX  loader.  This  "-X" 
switch  option  causes  all  C internally  generated  labels  to  be 
disregarded  while  retaining  only  those  symbols  local  to  the 
routines  themselves.  The  same  switch  is  also  used  in  the 
loading  phase  of  the  C compile  shell  command  "cc”. 

Provisions  in  the  compilation  phase  of  a BASIC  program 
ensure  the  emission  of  the  proper  assembly  language  code 
that  allows  interaction  between  the  BASIC  program  and  the  C 
subroutines.  Prior  to  the  actual  call  to  a subroutine,  the 
"eatern”  statement  causes  the  declaration  of  C subroutine 
ana  the  designation  of  the  type  and  number  of  parameters  to 
be  passed.  The  call  to  the  subroutine  is  done  by  the  "call" 
statement.  The  name  of  the  subroutine  and  the  actual 
parameters  passed  are  included  within  this  statement. 
Provisions  were  also  made  to  allow  the  user  to  assign  return 
values  from  the  subroutines  to  predefined  variables. 

Initial  investigation  into  Robertson's  BASIC  compiler 
proved  that  the  compiler  has  the  caoability  to  allow  BASIC 
programs  to  call  C language  subroutines.  Robertson's 
Extended  Basic  Users  Hanual  should  be  consulted  for  further 
details  concerning  usage. 

2.  Testing  and  Implementation 

Robertson  indicated  that  Extended  BASIC  could  interact 
with  subsystems  presently  used  at  the  Naval  Postgraduate 
School  Graphics  Laboratory.  Implementation  of  this  language 


H<th  the  Vector  General  software  was  never  accompHshed  by 
Robertson*  but  the  basic  feasibility  of  implementation  did 
evist.  The  first  tests  attemoted  in  this  development  were 
conducted  to  determine  the  correctness  of  calling  C 
subroutines  from  the  BASIC  program.  Problems  arose  in  the 
passing  of  floating  point  parameters.  In  order  for  such 
parameters  to  be  passed  and  aligned  correctly  within  core 
for  the  C subroutines*  the  values  expected  by  the  C 
subroutines  had  to  be  declared  as  double  precision  variables 
within  the  calling  program.  C I anguage  conventions  expect 
both  floating  point  and  double  precision  variables  to  be 
stored  in  64  bit  fields.  By  declaring  the  floating  point 
parameters  as  double  precision  within  the  "extern"  statement 
0^  BASIC*  the  problem  was  overcome.  Upon  the  completion  of 
successful  parameter  passing  between  BASIC  and  C 
subroutines*  continued  testing  was  undertaken  to  use  BASIC 
with  the  Vector  General  Library  in  drawing  pictures  on  the 
Vector  General  display. 

Since  development  of  the  Extended  Basic  compiler  and  its 
accompanying  software*  the  Graphics  Library  was  physically 
relocated  within  the  UNIX  file  system,  ^any  of  the  special 
deyice  libraries  were  also  renamed.  The  LBAX  shell  command 
had  to  be  updated  to  reflect  these  changes.  An  updated  copy 
of  the  source  and  executable  versions  of  the  special  device 
libraries  were  placed  on  the  system  for  general  use. 

In  preparing  a BASIC  program  for  execution  envolvinq  the 
Vector  General  display^  differences  were  noted  in  the  format 
of  BASIC  and  C programs.  The  C program  contained*  as  its 
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f\rtt  program  statemant» 


an 


"include"  statement 


Thorpe 


(11)  and  Stankowski  (101  required  this  statement  to  load  the 
initilixed  display  list  in  the-  proper  sequence.  The 
position  of  this  statement  in  the  program  ensured  that  upon 
comoi1ation«  the  display  list  would  be  located  at  the 
beginning  of  the  process's  data  segment  in  core  space.  The 
start  of  the  display  list  could  be  located  for  refreshing  by 
knowing  the  position  of  the  process's  data  segment. 

The  compilation  technique  mentioned  in  the  preceding 
paragraph  is  an  important  design  item  in  Visco's  Vector 
General  device  drivers  (151.  when  designing  the  device 
drivers#  Visco  had  to  ensure  that  the  start  of  the  display 
list  could  be  easily  located.  He  also  wanted  to  ensure  that 
with  a sharable  core  region,  the  only  segment  of  the  process 
located  within  this  region  was  the  data  segment.  By 
compiling  a C Vector  General  program  with  a "-i"  switch  set, 
the  file  generated  for  execution  is  designated  a 411 
filetyoe.  This  executable  file  is  distinguished  in  that  the 
text  and  data  segments  reside  in  separate  address  space  (6). 
Upon  execution,  the  start  of  the  data  space  is  aligned  at 
the  beginning  of  a 32  K word  boundary  in  core.  The  refresh 
cycle  is  accomplished  by  repeated  execution  of  the  display 
list  which  begins  at  this  32  K word  boundary. 

Two  major  problems  had  to  be  overcome  in  order  to  use 
the  Vector  General  display  with  a BASIC  program  that  called 
C subroutines.  Unlike  C,  BASIC  made  no  provisions  for  an 
"include"  statement.  BASIC  would  have  to  cause  the  loading 
of  the  initialised  display  list  by  some  other  means.  A 
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concatenation  of  an  i n i t i 1 i zat i on  list  could  not  be  appended 
to  tbe  beginning  of  the  BASIC  oroaram  because  of  the  failure 
of  the  language  to  recognize  certain  key  characters  within 
the  list.  Such  characters  as  the  or  underscore 
characterr  often  used  within  C variables#  are  unrecognizable 
and  return  error  conditions.  A decision  was  made  to  call  a 
dummy  C subroutine  which  would  cause  the  loading  of  the 
initialized  display  list  in  the  proper  seouence.  Such  a 
change  demanded  a modification  of  the  technique  by  which  the 
Vector  General  device  driver  locates  the  display  list  data. 


Visco's  temporary 

drivers  had  to 

be 

modified  to 

f i nd 

and 

communicate  the 

offset  of  the 

display 

list 

f rom 

the 

beginning  of  the 

data  segment. 

The  second 

major  problem 

that  was 

encountered 

i n 

development  of  BASIC  was  the  inability  of  BASIC  programs 
with  C subroutine  calls  to  be  designated  as  4ll  filetyoes 
upon  compilation.  The  standard  Hie  emitted  after  a BASIC 
compile  was  a 407  filetype#  text  and  data  being  mixed  within 
the  file.  ^<0  provisions  were  made  in  the  LBAX  shell  command 
for  inclusion  of  the  "-i"  switch  to  split  instruction  and 
data  space  ( I & 0 space  ).  Mhen  the  loading  phase  of  the 
shell  command  was  chanqeo  to  include  this  option#  execution 
of  the  final  executable  object  module  proved  unsuccessful. 
As  no  provisions  were  made  in  the  compiler  to  cause  data  and 
text  instructions  to  be  placed  on  separate  stacks#  the 
passing  of  various  oarameters  to  C subroutines  was  unable  to 
be  accomplished  correctly.  It  was  realized  that  changing 
the  BASIC  compiler  to  emit  the  proper  intermediate  assembly 
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language  code  was  beyond  the  scope  of  the  original  intent  of 
this  research. 


A different  approach  was  taken  in  an  attempt  to  overcome 
th#  problem.  This  approach  involved  implementing  a newly 
constructed  UNIX  operating  system  which  used  a segmented* 
process  memory  manager  in  conjunction  with  provisions  for 
shared  core  regions.  The  shared  core  regions  were  recently 
installed  in  the  hardware.  O'Dell  (51  implemented  such  a 
system  called  SUNIX  for  the  Naval  Postgraduate  School 
Computer  Laboratory.  One  version.  SSUNIX.  was  implemented 
for  the  POP-ll/50  processor  for  use  with  the  graohics 
display  equipment.  Although  not  operational,  this  hybrid 
UNIX  operating  system  was  planned  to  be  implemented  in  the 
computer  laboratory.  In  discussions  with  O'Dell.  SSUNIX  was 
described  as  a solution  to  BASIC's  problem  of  intermixing 
text  and  data  instructions.  SSUNIX  could  distinguish  and 
properly  execute  either  the  ail  or  a07  filetyoe  processes 
within  the  shared  memory  region.  The  generalization  of  the 
Vector  General  device  drivers  and  the  proper  interface 
between  the  drivers  and  the  SSUNIX  system  would  be  the  final 
items  to  reconcile  in  completing  the  implementation. 

Through  much  testing  and  debugging.  BASIC  was 
implemented  as  a second  h{gh*1evel  programming  language  for 
use  with  the  Vector  General  Graphics  Display  System. 
Portions  of  SSUNIX  had  to  be  modified  to  effect  this  goal. 
All  documentation  for  changas  to  SSUNIX  and  the  Vector 
General  device  drivers  are  discussed  in  following  sections. 
The  use  of  BASIC  as  a Vector  General  programming  language  is 
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p«*9Sented  in  Appendix  A of  the  Vector  General  User's 
Reference  Manual. 

C.  FORTRAN  IV-PLUS 

1.  Background 

Much  of  the  work  in  attempting  the  implementation  of  F<JP 
(FORTRAN  IV'Plus)  with  the  Vector  General  software  was 
similar  to  work  accomplished  in  the  BASIC  implementation. 
FflP  did  reauire  several  different  techniaues  for 
development.  More  development  work  is  needed  before  F4P  can 
become  completely  integrated  with  the  Vector  General 
software. 

F4P  was  developed  for  the  Digital  Couipment  Corporation 
(21  by  the  Commercial  Union  Leasing  Corporation  (CULC)  to  be 
implemented  under  the  UNIX  operating  system.  The  Naval 
Postgraduate  School  received  executable  versions  of  the 
compiler  but  had  np  access  to  the  source  code  for  it  or 
associated  software.  This  associated  software  included 
files  for  converting  regular  object  modules  into  FUP  object 
modules^  files  for  placing  F4P  object  modules  into  library 
format#  and  files  for  linking  F4P  object  modules  together 
into  an  executable  object  module.  Source  code  and 
documentation  were  not  available  during  the  development  time 
frame;  this  lack  of  documentation  and  source  for  Fap  and 
associated  routines  made  it  very  difficult  to  completely 
develop  FaP's  use  of  the  Vector  General  software. 

The  task  of  implementing  F4P  to  call  C subroutines 


IP 


proved  to  be  quite  different  than  that  of  the  BASIC  and  C 
integration.  Such  an  implementation  will  require  more 
research  and  testing  before  it  is  fully  accomol i shea.  Tmo 
important  items  of  imformation  were  known  about  F«P  and  its 
associated  software.  FaP  uses  "DEC  standard”  object 
modules;  these  are  quite  different  than  the  C object 
moaules.  Also*  prior  to  user  C object  modules  would  have  to 
be  converted  to  FaP  readable  object  modules. 

Two  software  items  were  available  which  were  advertised 
to  allow  FaP  proqrams  to  call  C programming  language 
subroutines.  The  "conv"  command  could  be  used  to  convert  a 
C object  module  into  an  FaP  readable  object  module.  with 
all  current  Vector  General  software  written  in  Cr  separate 
libraries  made  up  of  the  converted  C object  modules  would 
have  to  be  constructed.  The  "callc"  routine  was  the  second 
item  designed  to  complete  the  interface  between  the  FaP 
program  and  the  C subroutine.  This  routine  stacks  up 
parameters  for  C subroutinesr  eyecutes  the  external  C 
subroutine^  and  returns  to  the  calling  FaP  program. 

Differences  that  did  not  exist  in  the  BASIC 
implementation  were  encountered  in  the  calling  of  C 
subroutines  by  FaP  programs.  All  C subroutines  had  to  be 
separately  compiled  by  the  C compiler  into  object  modules 
prior  to  conversion.  The  FaP  "linker"  prohibits 
concatenated  subroutines  from  being  compiled  together  and 
properly  linked  with  the  calling  FaP  object  modules.  Also* 
as  previously  mentioned*  the  C subroutine  object  modules  had 
to  be  converted  to  FaP  readable  object  modules  by  the  "conv" 
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The  software  that  would  allow  the  communication  between 
F4P  and  C subroutines  is  the  "callc"  routine.  The  source 
for  this  routine  is  an  Ml]  assembly  language'  routine  which 
had  to  be  assembled  by  the  Macro  assembler.  This  Macro 
assembler  is  one  of  the  executable  files  which  was  included 
in  the  associated  software  supporting  the  F«P  compiler.  The 
resulting  "callc. obj"  and  a seldom  used  "callcv.obj"  modules 
provide  the  user  with  the  facility  to  place  the  parameters 
to  be  passed  to  the  C subroutine  in  a stack  and  to  jump  to 
the  C subroutine  which  is  called.  The  completion  of  the 
subroutine  allows  control  to  return  to  the  FaP  calling 
program.  The  "callc. obj"  module  would  have  to  be  included 
in  the  link  phase  of  all  the  modules  in  order  to  obtain  an 
executable  FaP  file.  An  important  feature  of  the  "callc" 
routine  is  that  it  works  with  pointers  to  the  parameters 
rather  than  the  parameters  themselves.  This  C parameter 
representation  necessitated  changing  the  C subroutines  to 
expect  pointers  to  the  parameters  instead  of  the  values  of 
the  parameters. 

In  dealing  with  the  reauirement  for  separate  compilation 
of  subroutines  and  the  call  by  name  parameter  passing*  a 
separate  Vector  General  library  was  needed  to  accomplish  the 
task.  The  "libr"  command  would  have  to  be  utilized  to  place 
the  modules  in  a single  library  similar  to  the  archive 
command  "ar"  within  the  C language.  Each  Vector  General 
Library  subroutine  had  to  be  updated  to  reflect  the  passing 
of  Upvalues  and  then  recompiled.  After  conversion  of  the 
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object  modules  Into  F4P  readable  object  modules^  tbe  modules 
Mould  have  to  be  olaced  in  a new  F<iP  Vector  General  Library. 
The  following  section  will  discuss  the  testing  and  attempted 
implementation  of  FaP  as  a third  language  capable  of  using 
the  Vector  General  software. 

2,  Testing  and  Implementation 

After  general  tests  were  conducted  and  proved  the 
ability  of  F4P  to  correctly  call  C subroutineSf  testing  was 
conducted  on  a simple  FaP  program  that  would  use  the  newly 
constructed  Vector  General  Library  of  FaP  object  modules. 
Two  non-fatal  errors  continued  to  arise  in  the  testing  runs. 
The  two  C library  subrouvines*  "ecvt"  and  "fcvt"»  were 
described  as  multiply  defined  in  the  error  listing.  Upon 
review  of  the  source  code  listings  for  the  two  items/  it 
became  evident  that  four  different  assembly  language 
subroutines  were  involved:  "^ecvt"»  "^fevt"/  "ecvt"/  "fevt". 
FaP  does  not  recognize  the  or  underscore  character/  but 
unlike  BASIC/  it  disregards  the  symbol  entirely.  Through 
continued  testing/  the  non-distinction  between  the  two 
similar  pairs  of  subroutine  names  was  found  to  be  no 
detriment  to  program  loading  and  execution.  Correction  of 
this  problem  would  reouire  rewriting  the  C subroutine  calls. 

A second  error  of  some  significance  was  found  while 
testing  proceeded.  According  to  C programming  language 
documentation  (71/  C allows  a user  to  assign  a floating 
point  value  to  an  integer  variable.  Such  an  assignment 
performs  truncation  towards  zero  on  the  floating  point  value 
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•nd  assigns  the  whole  number  value  to  the  integer  variable. 
An  inconsistency  was  found  in  the  methods  that  C and  F4P  use 
in  the  truncation  of  floating  ooint  numbers. 

the  converting  command  "conv"  was  found  to  change  this 
basic  coding  seouence  to  a seauence  which  placed  the 
truncated  floating  ooint  value  into  a long  integer  with  a 
'length  of  32  bits.  Such  a change  would#  in  effect#  cause 
only  the  uooer  16  bits  of  information  to  be  used.  To  remedy 
the  situation#  without  being  able  to  physically  update  the 
source  code  of  the  convert  routine#  all  instances  of  such  an 
operation  would  have  to  be  located  ana  corrected  within  the 
C subroutine.  Each  instance  was  changed  to  reflect  that  the 
integer  variable  was  a temporary  long  integer  variable. 
This  was  immediately  followed  by  the  long  integer  variable 
being  assigned  to  a 16  bit  integer.  The  change  was  proven 


effective  and  was  instituted  in  the  F^P  Vector  General 
Library  for  the  "vgabscale"#  " vgrel sea  1 e" # and  "vgpscal" 
rout i nes . 

After  continued  testing#  one  final#  fatal  problem  was 
discovered  with  the  interaction  between  the  FaP  and  the 
Vector  General  software.  Mhen  Vector  General  subroutines 
are  converted  into  FUP  readable  object  modules#  certain 
switches  are  set  by  default.  These  switches  govern  the 
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overlay  use  in  the  "linker”  phase  and  the  global  recognition 
of  different  segments  which  are  changed  to  "psects".  It 
becomes  possible  for  more  than  one  copy  of  global  variables 


In  checking  the  display  list  located  in  core#  two 
display  lists  were  found  to  e«ist#  each  containing 
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information  not  held  by  the  other.  Information  necessary 
for  refreshing  the  display  list  was  inaccessable  to  the 
device  drivers.  In  shorts  one  complete  updated  display  list 
did  not  exist. 

The  inability  to  implement  FOP  as  the  third  language 
capable  of  utilizing  the  Vector  General  Graphics  Display 
System  was  not  the  result  of  any  one  item.  The  lack  of 
source  code  for  the  software#  poor  documentation  on  FOP 
accompanying  software#  and  inherent  differences  in  the 
structure  of  C and  FOP  were  all  contributing  factors.  The 
implementation  of  FOP  in  the  Vector  General  environment 
should  be  Possible  by  obtaining  proper  documentation.  The 
final  hurdle  to  overcome  would  be  the  problem  of  multiple 
copies  of  the  display  list.  Recommendations  for  future  work 
in  this  area  will  be  made  in  the  final  chapter  of  this 
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IV.  GRAPHICS  SOFTWARE 


Modifications  and  enhancements  to  graohics  software  fall 
within  three  categories;  external  device  interfacing* 
display  list  supporting  software*  and  general  system 
i mpro vement  s . 


A.  EXTERNAL  DEVICE  INTERFACING 


The  external  devices  may  be  used  to  programat i ca I I y 
control  the  display  presentation.  Alphanumeric*  analog* 
logical*  positioning*  and  lightoen  data  may  be  returned  to 
the  user's  program  through  the  graohics  routines. 


1.  heyboard 

Alphanumeric  data  entry  is  accomplished  through  the 
Vector  General  keyboard.  Depression  of  any  key  enters  an  8 
bit  ASCII  character  code  into  the  keyboard  register  and  sets 
the  priority  interrupt  reouest  indicating  a character  has 
been  entered.  Upon  executing  the  interrupt  handler*  the 
character  code  is  placed  in  a keyboard  buffer  to  await  a 
call  from  the  user's  program.  The  "cget”  routine  was 
designed  to  return  the  data  entered  from  the  keyboard.  The 
"cget"  routine  buffers  the  data  until  a carriage  return  is 
received*  whereupon  the  entire  alphanumeric  string  is  made 
available  to  the  user's  program.  The  buffering  of  input 
data  was  designed  to  allow  erasing  of  erroneous  data.  As  no 
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data  is  available  to  the  user's  program  prior  to  a carriage 
return#  incorrectly  entered  data  may  be  removed  by  repeated 
control'a  keystrokes* 

The  "cget"  routine  solved  the  reauirement  for  returning 
alphanumeric  data  strings  to  the  user's  program. 
Determination  of  integer  and  floating  point  numbers# 
however#  presented  an  additional  problem.  Recognition  of 
integer  or  floating  point  numbers  from  a character  string 
reguires  the  conversion  of  ASCII  data  to  numerical  data. 
The  system-resident  C library  contained  two  routines#  ’"geti" 
and  "getf#  which  accomplish  the  desired  ASCII  to  integer  or 
float  conversions.  Use  of  the  system  routines  was  judged 
more  desirable  than  inventing  new  software. 

Two  new  routines#  "fget"  and  "iget"#  were  written  which 
set  condition  flags  and  pass  control  to  the  system  "getf" 
and  "geti”  routines  to  accomplish  the  conversions.  A new 
"getchar"  routine  was  written  to  replace  the  system-resident 
"getchar"  routine.  Upon  executing  either  the  "getf"  or 
"geti"  routine#  a call  is  made  to  the  new  "getchar"  routine 
to  obtain  a character.  Normally#  the  default  input  device 
would  be  interrogated  for  the  desired  character.  However# 
due  to  the  condition  flag  set  in  the  previous  execution  of 
the  "fget"  or  "iget"  routines#  the  "getchar"  routine 
reguests  the  character  from  the  Vector  General  keyboard. 
Repeated  calls  to  "getchar”  are  made  by  the  system  "geti" 
and  "getf"  routines  until  a carriage  return  is  received. 
The  routine  determines  the  integer  or  floating  point  number 
it  has  within  its  ASCII  string  and  returns  that  number  to 


th«  calling  routine.  The  result  is  that  the  user  is  able  to 
obtain  integer  or  floating  ooint  numbers  from  either  tha 
console  or  Vector  General  keyboard  without  an  excessive 
amount  of  additional  software. 

2.  Function  Switches 

The  iZ  lighted  function  switches  orovide  for  logical 
true/false  information  to  be  available  to  the  user's 
orogram.  Three  routines  were  added  to  enhance  the  use  of 
the  function  switches.  The  "fsman"  routine  was  designed  to 
return  the  status  of  the  desired  function  switch.  If 
physically  depressed,  a logical  value  of  true  or  one  (1)  is 
returned  to  the  user.  If  not  depressed,  a logical  value  of 
false  or  zero  (0)  is  returned. 

The  "lamp"  routine  was  designed  to  light  or  extinguish 
the  lamp  of  the  desired  function  switch.  No  dependence  on 
the  status  of  the  function  switch  is  inherent  in  the 
operation  of  the  "lamp"  routine.  The  routine  can  be  used  to 
light  a function  switch  to  indicate  that  a certain  condition 
has  been  attained. 

The  "fstog"  routine  was  designed  to  further  extend  the 
esse  in  utilizing  the  function  switches.  The  "fstog" 
routine  creates  the  illusion  the  function  switches  are 
toggles  which  flio*flop  their  logical  value  as  well  as  their 
lamp  status  with  each  depression  of  the  switch. 
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3.  Control  Dials 

Analog  information  is  made  available  to  the  user  through 
the  use  of  the  10  control  dials.  Integer  values  returned 
from  the  control  dials  vary  from  •20^8  to  2047.  the  maximum 
obtainable  from  the  12  bit  system  register.  Floating  point; 
values  returned  to  the  user  through  the  dial  routine, 
however.  vary  from  -1.0  to  1.0,  This  range  can  be  easily 
extended  within  the  user's  program.  Analog  values  obtained 
through  the  dial  routine  are  useful  for  adjusting  other 
program  variables  such  as  rotation  rates  and  translation 
speeds . 

4.  T rackbal I 

Previously  mentioned  devices  have  no  connection  with 
what  the  user  is  primarily  interested  in,  the  display 
screen.  The  trackball  is  an  external  device  designed  to 
provide  visual  positioning  feedback  to  the  user  of  data  on 
the  display  screen.  This  visual  feedback  is  obtained  by  the 
appearance  of  a small,  blinking  cursor  on  the  display 
screen,  Movemant  of  the  user's  hand  across  the  round, 
plastic  trackball  causes  the  software-generated  cursor  to 
move  in  an  appropriate  manner. 

The  display  of  the  trackball  cursor  is  accomplished  in  a 
manner  similar  to  other  elements.  A seguence  of  commands  is 
executed  by  the  display  controller  which  draws  a small  cross 
at  the  origin  of  the  X-Y  axis.  Each  refresh  cycle  the 
trackball's  X and  Y coordinate  registers  are  updated  and 
used  to  modify  the  coordinate  axis  of  the  cursor.  The 
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cursor  is  moved  reflecting  any  user  movement  of  the 
tractcball.  To  insure  cursor  display^  all  cursor  generating 
code  is  inserted  in  the  display  list  prior  to  the  code  for 
any  other  element. 

Two  routines  were  designed  to  be  used  with  the  trackball 
facilities.  The  "cursor”  routine  was  designed  to  activate 
or  deactivate  the  display  of  the  trackball  cursor. 
Activation  is  accomplished  by  ensuring  that  the  display 
controller  executes  the  cursor  drawing  code.  Deactivation 
is  accomplished  by  the  display  controller  skipping  the 
cursor  generating  code  within  the  display  list.  The  "posit" 
routine  was  designed  to  return  to  the  user's  program  the 
position  of  the  cursor  on  the  display  screen.  The  "posit" 
routine  returns  a floating  point  value  of  the  cursor's 
position  within  the  defined  coordinate  system  and  is  not 
dependent  on  the  active  display  of  the  trackball  cursor. 

5.  Joystick 

The  joystick  is  an  external  device  similar  to  the 
trackball  in  that  it  provides  visual  positioning  feedback  to 
the  user.  Unlike  the  trackballs  the  joystick  appears  to 
move  three-dimensional ly.  Movement  along  the  Z axis  is 
accomplished  by  variance  in  the  intensity  level  of  the 
blinking  joystick  cursor.  As  the  user  twists  the  joystick 
knob  to  move  the  cursor  further  back  into  the  display 
screen#  the  intensity  level  of  the  cursor  display  is  reduced 
giving  the  appearance  that  it  is  fading  into  the  distance. 

Joystick  cursor  generating  commands  are  inserted  and 
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uodattd  <n  the  display  list  just  like  the  trackball  cursor 
connands.  Both  the  "cursor”  and  "posit”  routines  work 
eoually  wen  for  the  joystick  with  the  addition  that  a Z 
dimension  is  available  for  the  joystick  "posit"  routine. 
Both  the  trackball  and  joystick  cursors  are  useful  in 
providing  the  user  with  visual  feedback  to  interactively 
position  display  elements. 

b.  Lightoen 

While  the  trackballs  joysticks  and  associated  cursors 
provide  positioning  informations  the  lightpen  is  unique  in 
its  ability  for  pointing  or  identifying  a portion  of  the 
display.  The  lightpen  does  not  write  on  the  screen,  but 
senses  light  from  the  disolav  on  its  photocell.  Not  all 
elements  drawn  on  the  display  screen  cause  lightpen 
interrupts.  An  element's  lightoen  enable  bit  must  be  set 
with  the  "Iqhtoen"  routine  or  no  lightoen  interrupt  will 
occur.  Once  the  enable  bit  is  set  and  the  operator  is 
pointing  the  lightpen  at  a portion  of  the  elements  the 
display  controller  causes  the  lightpen  interrupt  to  occur. 

The  objective  of  tne  lightoen  interrupt  handler  is  to 
determine  what  portion  of  the  display  caused  the  interrupt. 
After  appropriate  action  is  taken,  the  processor  is  allowed 
to  continue  what  is  was  eiecuting  prior  to  the  interrupt. 
To  determine  what  element  caused  the  interrupt  each  element 
is  given  an  element  number.  This  element  number  is  leaded 
in  a register  just  prior  to  the  actual  drawing  of  the 
element.  Ueon  encountering  a lightpen  interrupts  the 


interrupt  handler  interrogates  the  element  number  register 
to  determine  the  element  causing  the  interrupt.  Each 
element  has  a lightoen  flag  associated  with  it  within  the 
data  structures.  Upon  determining  the  element  which  caused 
the  interrupt  the  interrupt  handler  sets  the  appropriate 
flag  and  releases  the  processor  to  continue  what  it  was 
doing  prior  to  the  interrupt.  The  interrupt  handler  was 
kept  as  simple  as  possible  to  minimize  the  amount  of  time 
the  processor  must  spend  on  interrupts. 

Two  new  routines  were  designed  to  help  support  the 
lightpen  facilities.  The  "penhit"  routine  was  designed  to 
return  to  the  user  a logical  true/false  reply.  This  reply 
was  in  answer  to  whether  a particular  element  or  object  had 
generated  a lightpen  hit.  The  routine  determines  which 
element  or  object  is  in  ouestion.  checks  the  appropriate 
element  lightpen  flag^  and  returns  the  results  to  the  user. 
The  routine  was  made  general  enough  that  it  could  check  for 
a lightpen  hit  on  an  individual  element#  an  object#  or  the 
entire  picture. 

The  "cirhit"  routine  was  designed  to  clear  individual# 
groups#  or  all  elements  of  previous  lightoen  strikes.  The 
routine  resets  lightpen  flags  to  the  clear  position  in 
preparation  for  identifying  new  lightpen  strikes. 

Although  the  capabilities  of  the  lightoen  make  it  an 
ideal  device  for  pointing  or  identifying  portions  of  the 
display#  the  inclusion  of  additional  software  made  the 
lightpen  an  equally  good  positioning  device.  By  including 
additional  draw  commands  in  the  display  list  in  the  same 
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arta  aa  the  commands  for  the  trackball  and  joystick  cursors^ 
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a lightpen  cursor  mss  made  available  to  the  user.  The 
iightpen  cursor  is  an  octodon«shaoed  object  which  may  be 
moved  with  the  help  of  the  lightoen.  The  lightpen  cursor 
was  constructed  with  eight  elements  comprising  the  eight 
sides  of  the  cursor.  Upon  approaching  the  1 ightpen  cursor 
with  the  lightpen*  the  cursor  appears  to  latch  on  and  follow 
the  lightoen  about  the  display  screen. 

The  tracking  of  the  lightoen  cursor  is  accomplished  by 
determining  which  side  of  the  lightpen  cursor  first 
initiates  a lightoen  hit.  Moving  of  the  coordinate  axis  of 
the  cursor  is  then  accomplished#  minimizing  the  distance 
between  the  center  of  the  cursor  and  the  lightpen.  The 
determination  of  the  side  initiating  the  lightpen  strike  is 
accomplished  within  the  interrupt  handler.  Distinction 
between  the  sides  of  the  lightpen  cursor  and  other  lightpen 
bookable  elements  is  accomolished  by  oroviding  the  lightoen 
cursor  with  8 unigue  element  numbers. 

As  with  the  trackball  and  joystick#  two  routines  provide 
lightoen  cursor  positioning  information  to  the  user.  The 
"cursor”  routine  is  essential  in  activating  and  deactivating 
the  display  of  the  lightoen  cursor.  Unlike  the  trackball 
end  joystick  cursors#  the  lightoen  cursor  must  be  displayed 
to  be  updated.  The  "oosit"  routine  returns  the  floating 
point  position  of  the  lightpen  cursor  within  the  defined 
roordinate  system. 
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B.  DISPLAY  list  SUPPORTING  SOFTWARE 


In  reviewing^  revislnq*  and  extending  existing  software* 
many  tests  and  changes  were  required.  The  "arc"  and 
"circle"  routines  were  rewritten  to  orovide  for  correct 
manipulation  of  associated  center  and  endpoint  arguments. 
The  "setvector"  and  "endele"  routines  were  revised  to  ensure 
proper  termination  of  display  list  element  blocks  and  to 
correct  deficiencies  in  the  generation  of  auto*i nc rement 
arcs  and  circles.  The  "intscale"  routine  was  revised  and 
extended  to  allow  the  user  to  specify  whether  intensity 
cutoff  plane  provisions  were  to  be  in  effect.  Changes  to 
other  routines  included  additional  software  to  inhibit  error 
conditions*  and  correlating  routines  to  proviae  optimal  use 
of  available  display  list  space.  Three  routines  received 
particular  attention  and  require  a fuller  explanation. 

1.  Remove  Routine 

As  oriqinally  designed  the  graphic  system  data 
structures  provide  for  a display  list  of  a fixed  length  in 
size.  Should  all  the  display  list  be  utilized*  no 
additional  data  would  be  displayed.  For  example*  should  tne 
first  element  of  the  first  object  the  user  builds  use  up  the 
entire  display  list*  no  additional  elements  could  be 
displayed  even  though  only  one  element  of  one  object  had 
been  used.  Normally  such  a situation  would  not  occur; 
however*  should  numerous  large  elements  be  constructed  this 
same  problem*  lack  of  available  display  list  space*  could 
arise.  The  "remove"  routine  was  designed  to  halo  solve  the 


problem.  The  user  specifies  those  elements  no  longer 
essential  to  the  display  which  can  be  eliminated*  thereby 
creating  available  apace  within  the  display  list  for 
additional  elements. 

A somewhat  analogous  situation  occurs  within  the  memory 
management  techniouea  of  most  operating  systems.  Various 
methods  have  been  devised  to  recover  available  memory 
segments  and  reduce  fragmentation.  The  importance  of 
recovering  unused  or  fragmented  memory  space  in  memory 
management  technioues  cannot  be  overemohas i zed.  The 
efficiency  of  the  entire  system  may  depend  on  the  judicious 
use  of  available  memory.  As  the  importance  of  recovering 
available  display  list  space  for  a process  already  running 
in  memory  is  somewhat  lower  than  for  memory  management 
technioues*  a leas  sophisticated  method  was  designed  for  the 
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"remove"  routine. 

Upon  receiving  a list  of  nonessential  elements  from  the 
user*  the  "remove"  routine  seguentially  processes  the 
removal  of  each  block  of  element  commands.  The  freed  block 
is  burped  or  bubbled  through  the  display  list  by  moving 
succeeding  element  blocks  up  within  the  display  list.  The 
movement  of  element  blocks  within  the  display  list  requires 
the  adjustment  of  address  pointers  to  these  element  blocks 
to  ensure  proper  operation  of  the  display.  As  the  location 
of  active  element  blocks  are  moved  to  free  unused  memory 
locations*  disolay  list  refreshing  is  inhibited  during  this 
operation.  This  procedure*  though  costly  in  execution  time 
for  a series  of  elements*  was  deemed  more  suitable  than  a 
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fflor*  sophisticated  method  Mhich  would  have  cost  the  user 
additional  memory  soace*  Addi t i onal 1 v>  this  simple 
techniaue  was  preferred  because  the  "remove"  routine  was  not 
expected  to  be  used  so  freouently  within  a program  that  a 
momentary  delay  in  execution  would  be  noticed. 

2,  Printv  Routine 

As  originally  implemented#  the  graphics  software 
provided  for  only  one  tyoe  of  element  containing 
alphanumeric  data.  The  "charele"  routine  was  used  to 
specify  the  contents  of  the  character  string  which  could 
contain  any  of  the  characters  available  in  the  Vector 
General  character  set  plus  a few  format  instruction  codes. 
Provisions  for  changing  the  contents  of  an  element's 
character  string  were  nonexistent. 

A search  was  conducted  to  determine  the  most  feasible 
way  of  providing  for  an  element  which  could  handle  changing 
character  strings  and  also  provide  expanded  formatting 
capabilities.  The  success  of  the  "fget"  and  "iget"  routines 
in  using  system  routines  focussed  attention  on  the  system 
"printf"  routine.  The  "printf"  routine  converts#  formats# 
and  prints  its  parameters  after  the  first  argument#  under 
control  of  the  first  argument.  The  first  argument#  the 
format  argument#  consists  of  characters  and  conversion 
specifications.  It  was  felt  that  a combination  of  the 
"charele"  and  "printf"  routines  could  expand  the  use  of 
character  strings  used  within  the  Vector  General  Display 
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In  accomo H sh i ng  the  merger  of  the  "printf"  and 
"charele"  routines  two  new  routines  were  written.  The 
"orintw"  routine  contains  arguments  from  both  the  "charele" 
and  "printf"  routines.  Positioning  and  character  string 
initialization  arguments  are  similar  to  those  in  "charele" 
while  format  and  conversion  arguments  are  similar  to  the 
"orintf"  routine.  The  "orintv"  routine  oasses  its  format 
and  conversion  arguments  to  the  system  "printf"  routine  to 
accomplish  the  actual  converting  and  formatting  of  the  ASCII 
character  string.  As  the  "printf"  routine  must  call  the 
system  "outchar"  routine  to  output  charactersr  a newly 
designed  "outchar"  routine  was  substituted  for  the  system- 
resident  routine  to  output  characters  to  both  the  console 
and  Vector  General  display  screen. 

The  "printv"  routine  gives  the  user  a greatly  expanded 
capability  in  handling  character  strings.  Although  the 

; "orintv"  element  reouires  additional  display  list  space  over 

, that  of  a "charele"  element#  the  expanded  formatting  and 
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* conversion  capabilities  of  the  "orintv"  element#  in  addition 
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t to  its  ability  to  be  used  repeatedly  for  different  character 
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strings#  makes  it  a highly  useful  enhancement  to  the  display 


list  Supporting  software.  I 

i 

3.  Display  Routine 

As  mentioned  previously#  an  el ement *ob j ec t link  must  be 
established  to  display  elements  on  the  screen.  Mhile  both 
the  "remove”  and  "erase”  routines  caused  the  disappearance 
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of  an  elawent  from  the  display  screen*  no  routine  was 
available  to  activate  or  deactivate  the  display  of  an 
element  without  affecting  the  e 1 ement -ob j ec t association. 
The  "display”  routine  was  designed  to  accomplish  such  a 
purpose.  By  replacing  certain  graphic  commands  within  the 
display  list  with  subroutine  return  commands*  the  display 
controller  may  be  made  to  skip  execution  of  an  element's 
draw  commands.  This  effectively  deactivates  the  display  of 
the  element  without  affecting  the  e I emen t -ob j ec t 
associations.  Activation  of  the  element  is  then 
accomplished  by  reinserting  the  original  commands  in  the 
display  list  such  that  the  display  controller  executes  the 
element's  draw  commands  on  the  next  refresh  cycle.  The 
"display"  routine  allows  the  user  to  turn  an  element's 
display  on  or  off  without  affecting  the  necessary  element- 
object  associations.  Thus  the  number  of  routines  reguired 
to  activate  or  deactivate  an  element's  display  is  less  than 
if  either  the  "remove"  or  "erase"  routine  had  been  called. 

c.  general  system  improvements 

Many  of  the  revisions  and  extensions  to  system  software 
previously  mentioned  could  equally  qualify  as  general  system 
improvements  as  their  presence  ensures  a smoother  interface 
between  the  user  and  the  display  controller.  Of  particular 
concern  in  this  category  are  the  areas  of  system 
initialization  and  error  diagnostics. 
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1.  System  Ini  t i aH  zat  ion 

The  "svsinit"  routine  is  the  first  graphics  routine 
called  within  a user's  program.  The  routine  was  designed  to 
establish  links  from  the  user's  process  to  the  Vector 
General  display  unit  so  that  refresh  data  could  be  sent  to 
the  display  unit  and  external  device  information  could  be 
returned  to  the  user.  The  presence  of  two  Vector  General 
display  units  required  differentiation  between  units.  The 
user  specifies  the  desired  display  unit  with  the  argument 
passed  to  the  "sysinit"  routine.  To  insure  maximum 
opportunity  for  execution  of  a user's  program^  software  was 
added  that  attempts  to  link  a user  with  the  secondary 
display  unit  should  the  system  be  unable  to  link  to  the 
user's  primary  choice.  The  user's  process  is  terminated 
only  when  the  system  has  failed  in  attempts  to  link  the  user 
with  both  display  units. 

2.  Error  Diagnostics 

Recognizing  that  users  will  make  errors^  the  design  and 
implementation  of  error  detection  and  recovery  facilities 
was  identified  as  a necessary  expense.  The  price  paid  for 
error  detection  and  diagnostics  depends  upon  the 
sophistication  desired.  The  PL/C  compiler  is  an  example  of 
extremely  forgiving  and  diagnostically  helpful  software. 
Recognizing  that  such  a system  is  not  cheap  in  terms  of 

required  supporting  software^  the  requirements  for  a 

( 

reasonable  system  of  error  diagnostics  were  reviewed. 

It  was  felt  that  all  detected  errors  should  be 
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identified  to  the  user.  Presentation  of  error  diagnostics^ 
KoMever>  is  as  important  as  the  actual  error  detection. 
Cryptic  error  messages  with  numbers  which  must  be  looked  up 
in  manuals/  do  little  to  help  the  user  diagnose  problems. 
Concise  error  messages  which  identify  the  error/  the  routine 
where  it  occurred/  plus  give  reference  to  additional 
information  were  deemed  more  suitable  and  could  be  obtained 
with  minimal  overhead. 

The  error  diagnostic  routine  was  rewritten  to  provide 
the  user  with  four  items  upon  error  detection.  An  error 
type  is  specified  so  the  user  may  realize  what  has  caused 
the  error.  Additionally/  the  argument  in  error  and  the 
routine  in  which  it  occurred  are  specified  to  ensure  that 
the  user  pinpoints  the  problem.  Should  the  preceding 
information  be  insufficient/  the  last  item  provided  is  an 
error  number  with  which  the  user  may  obtain  a detailed 
explanation  of  the  error  from  the  Vector  General  User's 
Reference  Manual . 

Graceful  error  recovery  could  be  considered  an  art. 
Termination  of  a user's  program  upon  initial  error 
detection/  while  easily  accomplishable/  would  tend  to  not 
only  deflate  egos  but  also  discourage  potential  users.  All 
software  routines  were  designed  and  implemented  to  detect/ 
identify/  and  "gracefully*'  recover  from  user  errors. 
Although  the  detection  and  identification  of  errors  is 
fairly  standard  throughout  the  routines/  the  recovery 
methods  vary  from  routine  to  routine.  Within  some  routines/ 
default  parameters  are  assumed  upon  error  detection  to 


ensure  continuation  of  the  routine.  Other  instances  nay 
occur*  however*  where  no  default  oaraneter  could  be  assumed. 
In  such  instances  the  only  form  of  recovery  is  to  exit  the 
routine  and-  return  control  to  the  user's  program.  with  the 
exception  of  the  "sysinit"  routine*  no  routine  will  cause 
termination  of  the  user's  Program.  This  mss  done  to  ensure 
that  some  part  of  the  user's  display  is  presented*  providing 
the  user  some  amount  of  self-confidence  and  a starting  point 
for  using  the  error  diagnostics  to  Pinpoint  remaining  errors 
in  the  program. 


UNIX  system  was  currently  In  ooeratlon  at  the  Naval 
Postgraduate  School  Comouter  Laboratory  on  the  POP-ll/SO 
orocessors.  The  notable  accomplishment  of  the  SSUNIX 
operating  system  is  that  it  aligns  a process's  data  segment 
or  combined  data  and  test  segments  into  a region  of  shared^ 
dual'ported  memory.  The  process  image  is  then  locked  in 
this  memory  region  for  execution. 

Prior  to  O'Dell's  accomplishments#  Visco  1151  had 
suggested  that  Emery's  original  design  was  a promising 
technigue  for  allocating  a Vector  General  process's  data 
segment  into  a shared  memory  region.  This  dual*ported 
memory  region  could  subseguently  be  accessable  by  a slave 
processor  which  would  continuously  access  the  display  list 
data  by  DMA  (Direct  Memory  Access).  Visco's  slave  processor 
design  would  alleviate  the  POP*11/50  bus  tie-up  problem 
which  was  caused  by  the  high  interrupt  precedence  of  a 
refresh  cycle.  The  accessed i I i t y of  the  shared  memory 
region  by  the  main  processor  would  provide  the  real-time 
reguirements  for  multiprogramming  in  the  refresh  graphics 
environment.  Visco  believed  that  by  ensuring  only  data 
segments  would  be  located  in  the  32  word  shared  core 
region  there  would  be  greater  efficiency  and  less  likelihood 
of  having  programs  too  large  for  execution. 

A key  factor  for  the  implementation  of  SSUNIX  was  its 
propensity  to  distinguish  between  processes  where  data  and 
text  were  separated  segments  in  core  (411  filetypes)  and 
files  where  data  and  text  were  mixed  (407  filetypes). 
SSUNIX  causes  both  filetvoes  to  be  loaded  into  the  shared 
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n«mory  region  end  executed  alike.  SSUNIX  proved  to  be  the 


solution  to  the  oroblem  of  executing  the  BASIC  executable 
object  module  Mhere  test  and  data  reside  together.  Looking 
beyond  BASIC's  problemsr  SSUNIX  is  of  such  a general  nature 
that  other  user  languages  can  be  more  easily  implemented 
with  the  Vector  General  software.  The  future  integration  of 
F4P  with  the  SSUNIX  system  should  require  no  further 
modfications  to  SSUNIX. 


B.  MODIFICATIONS  TO  SSUNIX  SYSTEM  CODE 

Modifications  to  SSUNIX  were  made  in  two  general  areas: 
the  interface  code  between  the  user  and  the  system  software^ 
and  the  correction  of  the  process  for  allocating  core  prior 
to  locking  the  process  in  the  shared  core  region.  These 
changes  were  tested  and  instituted  in  the  SSUNIX  system. 
The  nature  and  explanations  for  the  changes  are  discussed  in 
the  following  paragraphs  in  this  section. 

The  first  modification  to  SSUNIX  was  the  updating  of  the 
shared  memory  region  parameters  located  within  the  "main" 
subroutine  of  the  system.  SSUNIX  is  alerted  by  "getshr" 
that  a shared  memory  region  of  core  is  requested  for 
execution  of  a process.  The  first  parameter  passed  to  the 
system  is  the  region  of  shared  core  that  is  requested. 
These  regions  of  shared  cere  are  assigned  the  identifying 
numbers  0 (blocks  2000  » 0000)  tnd  1 (blocks  5000  > 6000}. 
Each  block  of  core  represents  64  bytes  of  core  space. 
Region  0 i s 32  K words  in  size  while  region  1 is  16  K words 
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in  size*  Region  0 was  originally  declared  as  1000  blocks  in 
length  beginning  at  block  3000.  The  size  of  this  first 
region  had  to  be  corrected  in  SSUNiX's  "main"  routine.  The 
true  size  of  the  region  is  2000  blocks  in  length  beginning 
at  block  2000. 

The  second  modification  to  the  assembly  language  code  of 
"getshr"  was  the  addition  of  a oarameter  to  be  oassed  to  the 
system.  The  parameter  passed  is  the  address  of  the  first 
word  of  the  display  list.  The  address  represents  the  offset 
value  of  the  first  word  of  the  display  list  from  the 
beginning  of  the  data  segment.  If  the  text  and  data 
segments  are  not  split#  the  offset  is  from  the  beginning  of 
the  mixed  text  and  data.  This  method  identifies  the  first 
word  of  the  display  list  to  the  device  driver  whether  or  not 
text  and  data  were  split.  If  I & 0 space  were  split  and 
"vgdata”  was  included  at  the  bedinning  of  the  C program#  the 
offset  would  be  zero  indicating  that  the  display  list  starts 
at  the  beginning  of  the  process's  data  space.  If#  as  in  a 
BASIC  process#  I & 0 space  were  not  split  the  offset  would 
be  added  with  the  offset  of  the  data  segment  from  the 
beginning  of  the  shared  memory  region. 

Prior  to  the  inclusion  of  the  offset  address  in  tne 
"oetshr"  routine#  both  "getshr"  and  "freeshr"  had  to  be 
introduced  into  the  Vector  General  Library.  The  previous 
calls  to  "rtime"  and  "nonrtime"  under  the  UNIX  system  were 
Changed  to  "getshr"  and  "freeshr"  calls.  The  difference  was 
that  the  shared  memory  configuration  of  core  reguired  the 
Vector  General  processes  to  reouest  this  shared  core  region 
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In  order  to  use  tHe  offset  value  oassed  to  the  system  by 
tHe  "getshr"  call#  a small  routine  called  "vgdsoff"  was 
added  to  SSUNIX.  Mhen  "getshr”  is  called  by  the  Vector 
General  user  code#  a new  variable  " f i rstwdaddr"  is  assigned 
the  value  of  the  the  offset  of  the  first  word  of  the  display 
list.  The  "vgdsoff"  routine  returns  the  value  of 
" f i rat wdaddr"  to  a calling  routine  in  the  device  driver. 
The  only  routine  that  would  call  for  this  value  would  be 
"vgdevSO.c"  which  is  the  PDP-11/50  device  driver  for  the 
Vector  General  Display  Processor.  This  offset  value  passed 
to  the  driver  code  is  a key  factor  in  allowing  various  user 
languages  to  use  the  Vector  General  software.  without  this 
offset#  the  ability  to  generalize  the  refresh  method  for 
different  languages  would  be  difficult. 

The  final  modification  to  the  SSUNIx  system  was  the 
result  of  a condition  that  had  previously  gone  unnoticed, 
aith  the  help  of  O'Dell#  the  source  of  an  error  in  core 
allocation  by  SSUNIX  was  traced  to  a routine  called 
"malloc".  This  routine  allocates  soace  in  core  to  the 
process  being  loaded  by  first  checking  the  core  "free  map". 
The  "free  map”#  which  is  a mapping  of  free  cere  areas#  keeps 
track  of  the  areas  of  core  which  are  free  to  be  used  for 
storage  of  a process.  SSUNIX  first  swaps  a process  out  of 
core  onto  disk.  The  process  is  then  copied  back  into  core 
in  an  area  not  within  the  shared  memory  region  so  it  is  out 
of  its  Own  way.  "Malloc"  failed  to  take  into  account  that  a 
large  free  core  area  could  evist  from  just  below  the  upper 
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address  of  t^e  shared  memory  region  to  the  too  of  available 
core  area.  If  the  area  beneath  the  shared  core  region  was 
not  large  enough  to  store  the  orocessr  the  next  free  area  to 
be  checiced  would  be  this  large  area.  This  area  was 
unavailable  for  storage  as  the  set  flag  "sharflg"  indicated 
the  region  was  in  the  shared  memory  region.  As  the 
beginning  of  the  area  was  located  in  the  shared  core  region# 
the  entire  area  was  marked  unavailable  for  orocess  swapoing. 

A routine  called  "solitmao"  was  designed  and  implemented 
to  remedy  the  problem  by  updating  the  core  "free  map"  to 
reflect  that  the  region  above  the  upper  boundary  of  the 
shared  core  was  available  for  storage.  "Splitmao"  is  called 
in  the  "shalloc"  routine  just  prior  to  a call  to  "ceswao". 
"Ceswao"  originally  called  the  "malloc"  routine  to  assign 
the  core  area  for  temporary  storage.  "Splitmao"  changes  the 
representation  of  the  free  core  region  to  two  free  core 
regions  which  would  be  separated  by  the  upper  boundary  of 
the  shared  core  region.  The  area  within  the  shared  core 
region  would  not  be  used  due  to  the  set  "sharflg"#  while  the 
area  above  the  boundary  would  be  properly  allocated. 

Other  core  allocation  conditions  were  reviewed  to 
determine  if  additional  problems  could  arise.  No  other 
problems  were  noted#  and  the  updated  version  of  SSUNIX  was 
found  to  function  properly. 


C.  MODIFICATIONS  TO  DEVICE  DRIVER  CODE 


As  creviously  mentioned^  the  device  driver  code  for  the 
Vector  General  was  modified  to  allow  the  execution  of 
processes  with  or  without  split  text  end  data  segments. 
Visco  designed  the  original  device  drivers#  "nvgdev3<*.c"  and 
"nvgdevSO .c " » to  support  the  Vector  General  in  a multi- 
processor mode  of  operation.  The  two  processors  were  to 
interact  in  refreshing  and  updating  the  Vector  General 
display  list.  Inherent  in  the  design  was  the  assumption 
that  all  processes  would  be  of  the  ^11  filetyoe#  where  text 
and  data  segments  are  separated.  The  data  segment  would  be 
located  alone  in  the  sharable  core  region.  In  order  to 
discuss  the  modifications  to  the  drivers#  a brief 
description  of  each  driver  is  presented. 

The  "nvgdevi^.c"  driver  is  the  proposed  PDP-ll/3^ 
resident  device  driver  for  the  Vector  General.  It 
communicates  to  the  POP-II/SO  by  messages  that  are  passed 
through  a hardware  interface  device  called  the  OR-ll-K.  The 
driver  is  passed  several  items  of  important  information  by 
the  message  process:  the  offset  of  0 space  within  the  shared 
memory#  the  use  of  Vector  General  numbers  0 or  l;  and#  the 
time  to  begin  refreshing  the  display  list.  This  driver  is 
also  responsible  for  handling  the  interrupts  generated  by 
the  Vector  General  display  controller. 

The  "nvgdevSO. c"  driver  is  the  PDP-11/50  processor 
resident  device  driver  that  supports  the  Vector  General  in 


the  two  processor  mode 


This  driver  formats  and  sends 


mcssaqcs  to  th*  P0P-n/3«  orocessor  through  the  DH-ll-K 
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device.  The  messages  sent  by  this  driver  designate  the 
offset  of  the  data  soace  ^rom  the  beginning  of  the  32  K word 
shared  memory  region  to  determine  vhere  the  disolay  list 
begins  in  core. 

The  temoorary  device  drivers»  "tvgdev3«.c"  and 
"tvgdev50.c"»  were  designed  to  suooort  the  Vector  General  in 
a single  processor  mode.  The  two  drivers  were  originally 
written  by  Visco  to  simulate  and  test  the  operation  of  the 
two  orocessor  design  until  the  PDP-tl/3^  orocessor  could  be 
installed.  Both  tempory  device  drivers  will  continue  to 
drive  the  Vector  General  until  the  slave  processor  is 
integrated  into  the  system. 

The  drivers  were  designed  with  two  goals  in  mind.  The 
first  goal  has  been  discussed  before.  The  P0P«ll/3<i  driver, 
as  the  refresh  processor,  would  refresh  the  disolay  list. 
The  second  design  goal  was  that  the  PDP-11/50  driver  had  to 
inform  the  slave  orocessor  of  the  location  of  the  display 
list  for  refreshing  purposes.  In  generalizing  the  driver 
code  these  two  goals  remained  preeminent.  The  following 
paragraphs  document  the  exact  modifications  made  to  the 
device  drivers  currently  used  under  the  SSUNIX  operating 
system. 

1.  Modifications  to  TVGDEV50.C 

Only  one  addition  was  made  to  this  driver.  Mithin  the 
"vgooen"  routiner  a check  was  made  to  determine  if  1 & D 
space  was  split.  If  it  was  not  solitr  indicating  a 407 
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process#  a message  was  sent  to  the  34  device  driver  which 
passed  the  offset  of  the  first  word  of  the  display  list  from 
the  beginning  of  the  process.  The  message  was  distinguished 
in  the  34  driver  from  other  messages  by  virtue  of  its  sign 
bit  being  set.  The  message  was  constructed  by  setting  the 
sign  bit  for  the  value  returned  from  the  previously 
developed  "vgdsoff"  routine  within  SSUNIX.  A return  to  the 
SO  driver  was  made  after  the  message  was  processed  by  the  34 
driver.  The  use  of  the  messaaes  in  the  34  driver  will  be 
discussed  in  the  following  section. 

2.  Modifications  to  TVG0EV34.C 

The  functioning  of  the  34  device  driver  depends  on  the 
information  passed  to  it  by  the  50  device  driver.  Several 
modifications  had  to  be  made  to  the  driver  to  general{^e  the 
code  for  additional  language  i mo  1 ement at i on . The  first 
modification  was  the  processing  of  the  offset  message  passed 
by  the  50  driver  in  cases  where  I & 0 soace  was  not  split. 
This  message  is  received  by  the  "vg34com"  routine  and  is 
converted  to  a positive  value.  A new  variable# 
"sharmemof f " # is  set  to  the  passed  value.  The  value  of 
"sharmemoff"  remains  lero  if  a 411  process  is  executed 
because  the  variable  had  previously  been  initialized  as  zero 
and  no  additional  message  would  have  been  passed  to  the 
driver.  If  the  variable  had  a positive  value#  indicating  a 
407  process#  the  item  would  be  used  in  the  "vgopen”  routine 
located  within  the  driver  code.  Three  separate  variables 
depend  on  this  variable  for  determining  values  that  the 
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refresh  cycle  and  the  P0P-11/3U  memory  management  operation 
are  based  on. 

The  POP-n/3^  is  unable  to  address  items  in  a user's 
display  list  by  simply  referencing  symbol  names.  It  is  able 
to  address  only  the  32  K words  of  the  dusl*oorted  shared 
memory.  By  using  the  memory  management  hardware  and  the 
message  information  passed  by  the  50  driver#  the  correct 
physical  addresses  of  the  display  list  items  can  be  located 
in  core.  The  page  address  registers#  when  properly  set# 
allow  this  mapping  or  conversion  of  virtual  to  physical 
addresses  in  core  (11 . 

Three  variables  called  "vgpar"#  "vgreal"#  and  "po"  all 
involve  the  use  of  memory  management.  The  "oo"  variable  is 
a virtual  address  pointer  that  can  be  used  in  addressing  any 
item  in  the  display  list  which  resides  in  the  shared  memory 
region  of  core.  This  variable  can  be  used  to  address  up  to 
a K words  of  core  which  is  more  than  adeauate  for  addressing 
the  several  hundred  words  in  the  display  list  that  might  be 
addressed. 

The  result  of  the  modifications  made  to  this  device 
driver  was  the  correct  refreshing  of  both  «07  and  all 
filetyoe  processes.  All  other  added  items  within  this 
driver  reflect  additional  interrupt  handling  capabilities 
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VI.  CONCLUSIONS  AMO  RECOMMENDATIONS 


The  primary  objective  of  work  described  in  this  thesis 
was  the  i mp1 ementat i on  of  enhanced  user  software  with  the 
Vector  General  Display  System.  This  objective  was  attacked 
on  two  fronts.  The  first  approach  was  to  test/  correct/  and 
e»pand  the  software  previously  available  on  the  system/ 
which  would  improve  user  interaction.  The  second  approach 
was  to  implement  other  user  lanquages/  specifically  versions 
of  BASIC  and  FORTRAN,  with  the  Vector  General  software. 
Together,  the  two  approaches  provided  the  successful 
implementation  of  a package  which,  better^  supports  user 
interaction  with  the  Vector  General  Display'  System.  This 
chapter  provides  further  recommendations  to  improve  the 
system  in  the  areas  of  the  display  list  design,  language 
development,  and  system  software  implementation. 


A.  display  list  design 

In  the  present  design  of  the  Vector  General  software,  a 
structure  within  the  display  list  is  utilized  to  store  user 
commands  to  be  executed  on  the  Vector  General  display.  This 
structure  "vgdibuf"  is  of  a fixed  length,  a K words  of  the 
shared  memory.  An  improvement  in  this  technique  of  having  a 
fixed  length  display  list  could  be  investigated.  One 
possibility  would  be  the  implementation  of  software  to 
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increase  the  size  of  the  structure  Mhich  would  utilize  the 
unused  portion  of  the  sharable  memory  region.  This  software 
implementation  would  be  useful  when  no  other  process  needs 
the  shared  memory  region  and  the  parent  process  requires 
additional  core  space. 

B.  LANGUAGE  DEVELOPMENT 

FttP  (FORTRAN  lV-P1us)  was  not  completely  implemented 
with  the  Vector  General  software  due  to  problems  encountered 
with  the  interaction  between  the  FUP  and  C languages.  It  is 
recommended  that  investigation  continue  in  reconciling  the 
"overlay"  problem  caused  by  C converted  subroutines  having 
more  than  one  copy  of  globally  declared  variables. 
Prerequisite  to  understanding  this  problem  is  tne 
acquisition  of  source  code  and  documentation  for  the  Fap 
compiler#  the  "conv"  subroutine#  and  the  FUP  "linker". 
Completion  of  the  the  FaP  and  C interface  would  further 
expand  the  utilization  of  the  Vector  General  Graphics  System 
to  users  with  knowledge  of  other  languages. 

The  inability  of  Robertson's  BASIC  compiler  to  split  I A 
0 space  is  viewed  as  a less  important  problem.  SSUNIX  and 
driver  design  modifications  were  implemented  to  overcome 
execution  problems  of  the  BASIC  Vector  General  programs. 
The  expense  of  BASIC’s  inability  to  split  text  and  aata 
segments  required  the  allotment  of  more  shared  memory  in 
loading  the  combined  text  and  data  segment.  By  networking 
the  Compiler  to  allow  the  stacking  of  date  and  text  in 
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separate  data  and  text  seqmentsr  more  complex  BASIC  programs 
could  be  executed  in  the  shared  core  region  allotted  for 
execution.  Additional  testing  of  large  BASIC  programs  could 
help  determine  the  limitations  of  loading  both  text  and  data 
segments  into  the  shared  memory  region. 

C.  SYSTEM  SOFTWARE  IMPLEMENTATION 

An'^  increasing  item  of  importance  to  the  software 
developed  i n^  this  thesis  and  previous  software  work  is  the 
continuing  support  of  the  SSUNIX  operating  system  in  the 
Naval  Postgraduate  School  Graphics  Laboratory.  It  is 
recommended  that  increasing  emphasis  and  testing  be  placed 
on  SSUNIX  while  running  in  a davto-day  operational 
environment  to  ensure  its  reliability. 

The  implementation  of  the  P0P-11/3U  processor  in  a 
dual “Processor  mode  with  the  POP-ll/SO  processor  should  be 
of  primary  importance  for  the  Vector  General  Display  System 
to  alleviate  the  current  bus  tie-up  problem.  An 
investigation  into  the  communication  requirements  between 
the  slave  and  the  master  processors  should  be  conducted. 
The  hardware  interfaces  for  the  32K  word  shared  core  region 
and  the  Vector  General  display  device  should  also  be 
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USER'S  REFERENCE  MANUAL 

The  Durpose  of  this  document  is  to  orowide  the  user  with 
the  information  necessary  to  execute  proqrams  employinq  the 
Vector  General  qraohics  display.  This  manual  was  oriqinally 
prepared  by  B.  J.  Stankowski  in  June  1976  and  revised  by  N. 
P.  Martino  and  0.  C.  Endicott  in  December  1977, 

Section  I provides  a brief  introduction  to  the  Vector 
General  display  system#  the  software  support  library#  and 
the  prerequisites  for  their  effective  utilization.  Section 
II  describes  the  Vector  General  system  in  more  detail# 
expanding  upon  the  hardware  features#  system  interface#  and 
external  device  capabilities.  Section  III  contains 
information  on  the  initialization  of  the  Vector  General 
display  system.  Section  IV  describes  the  display 
composition#  element  construction#  and  picture#  object#  and 
element  relationships.  Section  V provides  a brief 
. description  of  the  user  support  routines  available  in  the 
support  library.  Finally#  Section  VI  provides  information 
necessary  for  compiling  and  executing  user  programs 
employing  the  Vector  General  graphics  display  unit. 
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I.  INTRODUCTION 


The  Vector  General  Is  an  Interactive  graohics  display 
system  which  has  been  interfaced  with  the  PDP*ll/50 
computer.  The  display  interacts  with  a POP-11  user  by 
displaying  pictorial  information  on  the  surface  of  a cathode 
ray  tube  and  by  accepting  information  from  its  external 
control  devices.  The  external  devices  consist  of  an 
alphanumeric  keyboardr  32  lighted  function  switches*  10 
control  dials*  a trackball*  a joystick*  and  a lightoen. 

An  interactive  graphics  software  program  library  has 
been  constructed  to  interface  the  user  and  the  Vector 
General  display  controller.  The  software  package  provides 
the  user  with  sufficient  routines  to  easily  construct  and 
manipulate  graphic  displays.  Although  the  routines  were 
written  in  C*  the  user  has  the  choice  of  two  high-level 
languages  with  which  to  program.  BASIC  programs  may  now 
also  interface  with  the  Vector  General  through  the  use  of 
the  routines  in  the  software  support  library. 

This  manual  does  not  attempt  to  discuss  in  detail  the 
electronic  functions  of  the  Vector  General*  or  its  interface 
with  the  POP-11.  The  purpose  of  this  manual  is  to  instruct 
a user  in  the  creation  and  manipulation  of  pictorial  data  on 
the  Vector  General  display.  A knowledge  of  C or  Basic  is 
assumed. 
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I II.  THE  VECTOR  GENERAL  DISPLAY  SYSTEM 

A more  detailed  discussion  of  tSe  Vector  General  can  be 

i 

found  in  the  Users  Manual  for  the  Vector  General  Display 
Unit  (12)  and  the  Design  Manual  for  the  Vector  General 
Display  Unit  (111. 

A.  THE  display 

The  Vector  General  is  a cathode  ray  tube  (CRT)  display 
on  which  a visible  pattern  can  be  created  by  the  movement  of 
L an  electron  beam.  The  electron  beam  causes  a florescent 

soot  to  appear  on  the  face  of  the  display  tube.  The 
movement  of  the  beam  is  controlled  by  a method  called  random 
scan»  which  in  effect  steers  the  spot  in  a straight  line 
between  two  points  on  the  display  screen.  The  resulting 

line  or  vector#  combined  with  others#  creates  a picture  or 

i 

pattern  on  the  display  screen. 

I To  maintain  a clear  picture  on  the  display  screen 

1 

requires  that  the  pattern  be  redrawn  on  the  tube  repeatedly 
at  approximately  thirty  to  forty  times  a second.  Each 
repetition  is  called  a frame  and  the  frequency  with  which  it 
is  redrawn  is  called  the  refresh  rate.  If  the  pattern  is 

i 

not  repeated  often  enough  a degradation  of  the  picture  will 

j 

I occur  on  the  display  screen.  This  degradation  is  called 

f I icker. 


B.  HAROMARE  FEATURES 


Th«  system  has  several  hardware  features#  in  addition  to 
a vector  generator#  which  greatly  extend  its  capabilites. 
These  include  the  ability  to  produce  three-dimensional 
figures#  an  ASCII  character  set#  and  the  hardware  generation 
of  arcs  and  circles.  Other  features  provide  the  hardware 
mechanisms  for  the  rotation  and  translation  of  user 
specified  picture  segments.  These  hardware  features  are 
controHed  and  coordinated  by  the  display  controller.  The 
controller  is  responsible  for  handling  the  communications 
between  the  user,  the  external  control  devices  and  t"te 
display  hardware. 

The  main  purpose  of  the  external  control  devices  is  to 
facilitate  user  interaction  with  the  display.  These  devices 
include  an  alphanumeric  keyboard#  32  lighted  function 
switches#  10  control  dials#  a trackball#  a joystick#  and  a 
1 i ghtpen. 

Additional  information  on  the  Vector  General  hardware 
can  be  found  in  the  Graphics  Display  Reference  Manual  113] 
and  the  Graphics  Display  System  Technical  Manual  (IRl. 

C.  THE  SYSTEM  INTERFACE 

A Vector  General  user  defines  pictorial  data  end  its 
manipulation  within  a Basic  or  C program.  The  execution  of 
the  program  causes  the  Vector  General  software  interface  to 
be  activated.  It  is  this  software  which  communicates  user 
reguests  and  receives  informetion  from  the  Vector  General 
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controller.  The  softMare  oasses  user  requests*  in  the  proper 


form*  to  the  diolay  controller.  The  controller  will 
activate  the  orooer  hardware  generator  (ie.  character* 
vector*  • arc/circle)  which  will  output  the  desired 
information  on  the  diolay  screen.  The  controller  will  also 
pass  information  from  the  external  control  devices  back  to 
the  user  via  the  interface  software.  This  relationship  is 
illustrated  in  figure  A-1, 


Interface  Relationship  with  the  Vector  General 

FIGURE  A-l 


0.  INTERFACE  elTH  EXTERNAL  DEVICES 


Each  of  the  the  external  devices  communicate  directly  to 
the  Vector  General  controller.  Information  from  these 
devices  is  returned  to  the  user  via  the  controller  and  the 
user  interface.  The  user  oroqram  may  utilize  the  information 


returned  from  these  devices  to  control  program  flow.  This 
allows  a user  to  interactively  control  and  manipulate  the 


pictorial  information  at  display  time.  Specific  user 
routines  which  activate  these  external  devices  and  provide  a 
communications  channel  with  the  user  are  discussed  in  detail 
in  later  sections  of  this  manual. 

1.  Alphanumeric  Keyboard 

The  alphanumeric  keyboard  allows  the  user  to  input 
information  in  tha  form  of  ASCII  character  codes.  Through 
the  user  interface  the  user  can  display  the  information  on 
the  Vector  General  display  screen.  The  data  entered  from 
the  keyboard  can  also  be  returned  to  the  user  program  for 
processing. 

2.  Function  Switches 

The  32  lighted  function  switches  provide  the  user 
I with  information  which  can  be  used  to  interactively 

I manipulate  oictorial  data  at  disolay  time.  Each  function 

switch  can  be  assigned  specific  meaning  by  the  user  program. 

j 

The  user  interface  returns  to  the  user  information  on  which 
) function  switches  have  been  pressed.  A user  program  could 

use  this  information  to  selectively  rotate*  translate  or 

perhaps  scale  particular  picture  segments. 


3.  Control  Dials 
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softMarc»  can  be  orovided  to  the  user.  A user  program  may 
utHize  tKe  values  of  the  variable  control  dials  in 
determining  the  distance  or  rate  at  which  a portion  of  the 
picture  may  be  moved  or  rotated. 

<*•  rrackoal  I 

The  trackball  is  an  external  device  which  uses  a 
software-generated  blinking  cursor  to  provide  visual 
positioning  feedback  to  the  user.  The  rolling  action  of  the 
user's  hand  across  the  round  trackball  steers  the  cursor 
about  the  display  screen.  A routine  is  available  to  return 
the  trackball  cursor  position  within  the  defined  coordinate 
system  so  the  user  may  programat i cal  1 y use  this  information. 
Addi t ional 1 y»  a routine  is  available  to  activate  or 
deactivate  the  display  of  the  software-generated  cursor. 
Positioning  information  may  be  returned  to  the  user  whether 
or  not  the  cursor  is  displayed. 

5.  Joystick 

The  joystick  is  an  external  device#  which  like  the 
trackball#  uses  a software-generated  blinking  cursor  to 
provide  positioning  feedback  to  the  user.  Unlike  the 
trackball  which  moves  about  only  the  X-T  plane#  the  joystick 
cursor  appears  to  move  in  three  dimensions.  Movement  about 
the  X-Y  plane  is  accomplished  by  Pushing  the  joystick  fore- 
aft#  and  side-to-side.  Movement  along  the  Z axis 
(perpendicular  to  the  display  screen)  is  accomplished 
manually  by  twisting  the  knob  on  top  of  the  joystick  and 
visually  on  the  screen  by  using  the  depth-cueing  facilities 
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•nd  varying  the  cursor  intensity.  Like  the  trackban» 
routines  are  available  to  return  to  the  user  the  joystick 
cursor  Dosition  and  activate  or  deactivate  the  display  of 
the  cursor, 

6.  Lightoen 

The  lightoen#  a wand  containing  a photo  cell#  can  be 
used  to  selectively  point  to  different  picture  segments  on 
the  display  screen.  The  interface  provides  a user  orogram 
with  information  on  which  picture  segment  was  pointed  to  by 
the  Hghtpen,  A user  program  can  turn  the  lightpen 
sel ectabi 1 i ty  of  specific  picture  segments  on  or  off.  For 
esample#  a user  might  select  sections  of  a picture  for 
erasure  by  pointing  to  them  with  the  lightpen. 

The  software  additionally  provides  for  generation  of  a 
lightpen  cursor.  The  lightpen  cursor  is  a small  non- 
blinking octagon  which  may  be  moved  about  the  display  screen 
with  the  lightpen.  Two  speeds  of  lightpen  movement  are 
available.  Routines  for  returning  the  lightpen  cursor 
position  and  activation/deactivation  of  the  cursor  display 
are  available  within  the  software  package. 


in.  INITIALIZATION 


A.  interface  initialization 

The  Vector  General  display  .system  and  the  graphics 
software  with  the  P0P*11  must  be  initialized  before  any  data 
can  be  displayed.  The  initialization  routine  sysinit  must 
be  called  before  any  other  routines  are  utilized.  This 
routine  sets  all  the  system  default  parameters^  such  as  the 
screen  coordinate  system. 

If  for  some  reason  the  initialization  cannot  be 
completed  the  user  program  will  be  terminated.  This  error 
usually  occurs  because  another  user  is  accessing  the  Vector 
Genera  1 . 

8.  DISPLAY  INITIALIZATION 

1.  Coordinate  System 

The  user  can  specify  a two  or  three-dimensional 
cartesian  coordinate  system.  All  display  coordinate  values 
referenced  by  the  user  will  be  interpreted  according  to  this 
coordinate  system  definition.  A user  may  redefine  the 
coordinate  scale  at  any  time  in  a program.  The  user  will 
define  the  coordinate  system  in  a call  to  the  routine 
coordsys . 

coordsys(dim*min)i#maxx»miny»ma)iy  frminzrmaxz}  ) ! 
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The  routine  reauires  the  user  to  specify  if 


the 
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coordinate  system  is  to  be  two  or  t hree~di mens i ona I and  the 
range  of  each  coordinate.  If  the  parameter  'dim'  is  two» 
indicating  a two-dimensional  coordinate  system  is  desired# 
the  range  of  the  z coordinate  can  be  omitted#  and  wilt  be 
ignored  if  it  should  be  included. 

If  this  routine  is  not  called  by  the  user  the  default 
coordinate  system  will  be  used.  This  default  system  is 
defined  as  three-dimensional  with  the  x»  y#  z coordinates 
ranging  from  -100.0  to  100.0.  All  coordinate  values  will  be 
interpreted  by  this  default  system  when  coordsys  is  not 
called  by  the  user. 

As  will  be  discussed  later  in  this  manual#  both  absolute 
and  relative  vectors  may  be  utilized  in  constructing  display 
elements.  Should  an  absolute  coordinate  be  specified  which 
falls  outside  the  defined  coordinate  system#  a value  of  the 
nearest  coordinate  within  the  defined  system  will  be 
assumed.  Should  a relative  increment  be  specified  which 
exceeds  one-half  the  coordinate  range  (ie:  100  for  default 
coordinate  system)  a value  of  zero  will  be  assumed. 

2,  Picture  Scale 

The  rectangular#  13  by  14  inch#  portion  of  the 
display  screen  that  can  be  viewed  by  the  user  is  called  the 
visible  space.  The  maximum  picture  space  is  larger  than  the 
visible  space#  covering  an  area  of  30  by  30  inches.  This 
extra  area  allows  a user  to  rotate  or  move  part  of  the 
picture  to  the  extreme  boundaries  of  the  visible  space 
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without  any  distortion.  It  also  oermits  limited  rooming 


The  pictorial  data  being  displayed  can  be  adjusted  in 
sire»  or  scaiedr  by  two  different  controls.  One/  the  gain 
control  dials  on  the  Vector  General  display  unit  allow  the 
user  to  manually  manipulate  the  picture  scale.  The  second 
provides  scale  control  within  the  user's  program  by  calling 
the  routine  pscale.  This  routine  is  discussed  in  detail  in 
Section  V of  this  manual. 


IV.  CREATING  A PICTURE 


A.  PICTURE  STRUCTURE 

All  of  the  information  that  a user  desires  to  display  on 
the  Vector  General  must  be  incorporated  into  the 
hierarchical  picture  structure  defined  by  the  interface 
softMare.  The  three  hierarchical  levels  are  defined  as: 
picture#  object#  element.  These  levels  specify  the 
underlying  structure  of  the  graphical  display  and  determine 
the  operations  a user  can  oerform  on  information  associated 
with  each  1 evel . 

The  term  picture  refers  to  all  of  the  data  that  is  to  be 
displayed  on  the  Vector  General  display  space.  The  term 
element  refers  to  the  smallest  picture  segment  which  can  be 

i 

independently  referenced  and  changed  without  affecting  the 
remainder  of  the  picture.  Each  element#  or  independent  I 

picture  segment#  has  a uniaue  name  associated  with  it.  A 
collection#  or  meaningful  grouping#  of  elements  is  called  an 
object.  Each  object  is  also  labeled  by  a uniaue  name  so  it 
can  be  easily  referenced  by  a user.  Figure  A«2  illustrates 
the  relationship  of  the  three  levels  in  the  actual  structure 
of  a picture. 

An  element  is  completely  described  and  named  by  the 
user.  It  can  describe  either  graphical  or  ASCII  character 
data.  An  element  can  be  i ndeoendent 1 y added  or  erased  from 
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Hierarchical  Picture  Structure 
FIGURE  A-2 
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display  screen.  It  can  be  caused  to  blink  or  be 
specified  as  being  Hqhtpen  selectable. 

Each  element  must  be  associated  with  at  least  one  object 
before  it  can  be  displayed  on  the  Vector  General.  An  object 
may  consist  of  from  one  to  ten  elements.  A user  is 
responsible  for  establishing  the  desired  ob j ec t *el ement 
association^  and  for  specifying  a unique  name  for  each 
object.  Each  user  defined  object  can  be  independently 
rotated#  or  translated  to  any  section  of  the  30  by  30  inch 
display  soace.  An  object  can  be  added  or  erased  from  a 
picture#  scaled#  and  specified  to  blink  or  to  be  lightoen 
selectable.  Each  object's  intensity  can  be  varied  in  order 
to  give  three-dimensional  objects  their  depth  queuing.  These 
actions#  Mhen  applied  to  a specific  object#  affect  every 
element  that  has  been  associated  with  it  by  the  user. 

A picture  may  contain  from  one  to  ten  objects.  The 
coordinate  scale  and  picture  scale  defined  by  the  user 
affects  the  entire  oicture.  A picture's  coordinate  scale 
can  be  varied  but  this  action  Mill  affect  every  object 
defined  as  oart  of  the  picture.  An  entire  oicture  can  also 
be  erased#  specified  to  blink  or  be  lightoen  selectable. 

A sumnary  of  the  operations  for  each  level  of  the 
hierarchy  is  outlined  in  Figure  A-3. 
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Summary  of  Operations  Associated  with  Each  Hierarchial  Level 

FIGURE  A-3 


B.  CONSTRUCTING  AN  ELEMENT 

Every  element  is  completely  described  by  the  user  within 
an  element  block.  There  are  two  types  of  element  blocks.  A 
draw  element  block  describes  graphical  information.  A 
character  element  describes  ASCII  characters  that  are  to  be 
displayed.  Each  element  is  uniquely  named  and  this  name 
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wHI  be  used  to  reference  this  particular  structure. 

1.  Draw  Element  Block 

A draw  element  block  represents  a group  of  draw 
instructions  that  describe  a specific  structure#  or  picture 
segment.  These  draw  instructions  include  setvector#  move# 
line#  arc  and  circle.  A draw  element  block  begins  with  a 
call  to  the  routine  drawele  and  is  terminated  by  a call  to 
the  routine  endele.  The  draw  instructions  that  are  executed 
between  drawele  and  endele  describe  the  actual  picture 
segment . 

The  only  oarameter  reguired  by  drawele  is  a guoted 
character  string#  or  pointer  to  a character  string# 
specifying  the  name  the  user  wants  to  associate  with  this 
element.  This  name  will  be  used  throughout  the  program  to 
reference  this  element  block. 

The  basic  draw  element  block#  and  the  related  draw 
instructions  are  represented  in  the  following  format: 

— drawele("element-name") » 

! setvector (vtyoe# vmode# (inc) # (scale! )# 

• 

I • 

I 

f • 

$ 

I • 

5 — setvector (vtype# vmode# (inc! # (scale! 1; 

S I move(x#  (yl # (zl  ) # 

! ! I ine(x#  (y! # (zl  ) ; 

! ! c i rc I e(di r#cent X # (centy! # (cent zl  ) ; 

S arc (di r#cent X # (centy! # (cent z! # endx # (endy! # (endz!  ) » 

I 

I • 

» 

I • 

I 

$ • 

— endeleO: 

The  user  can  select  one  or  more  of  twelve  vector  types 
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in  constructing  an  element.  These  vector  types  describe  how 
the  coordinate  data  will  be  interpreted  in  drawing  a vector 
on  the  display  screen.  The  choice  of  a vector  effects,  the 
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parameters  that  will  be  passed  in  each  of  the  move.  line, 
circle  or  arc  instructions.  The  user  specifies  a vector 
selection  by  calling  the  routine  setvector. 


a.  Setvector 

This  draw  instruction  must  be  called 
immediately  after  drawele.  and  may  be  called  any  number  of 
times  within  the  element  block.  Each  setvector.  and  the  draw 
instructions  that  follow  it.  comprise  a subgroup.  The 
setvector  instruction  determines  the  manner  in  which  the 
line.  move,  arc  and  circle  instructions  in  the  subgroup  will 
be  interpreted,  as  well  as  their  visual  appearance  on  the 
display  screen.  The  routine  is  called  with  the  followino 
parameters: 


setvector(vtype. vmode  [.incl  (.scale!): 


The  parameter  vtype  specifies  which  one  of  the  twelve 
vector  types  the  user  wants  the  following  group  of  line, 
move,  arc  and  circle  instructions  to  utilize.  The  parameter 
vmode  indicates  the  vector  mode,  or  appearance  of  the 
vectors  to  be  drawn  (ie.  solid  line,  dotted  line.  etc.). 
Certain  vector  types  reouire  additional  information;  this 
information  is  specified  by  the  parameters  inc  and  scale. 

A brief  summary  of  the  twelve  vector  types  is  listed  in 
Table  A-I, 


TABLE  A-I 


SUHARY  OF  VECTOR  TYPES 


NAME  DESCRIPTION 

VA  • vector  absolute;  each  coordinate  Is  soecifled 
with  respect  to  the  oripin.  Each  poIntCsfVfZ) 
references  a unique  oolnt  on  the  display  screen. 

VAX  • vector  absolute  auto*l ncrenent  every  draw 
Instruction  causes  the  y and  z absolute 
values  to  be  uooated  while  » Is  stepped  by  a 
constant  value. 

VAY  - vector  absolute  auto*l ncrement  yt  every  draw 
Instruction  causes  the  v and  z absolute 
values  to  be  updated  while  y Is  stepped  by  a 
constant  value. 

VAZ  • vector  absolute  autO“lncre*ent  zi  every  draw 
Instruction  causes  the  x and  y absolute 
values  to  be  uooated  while  z Is  stepped  by  a 
constant  value. 

vR  - vector  relative;  each  x^  y»  z coordinate 
value  Indicates  the  amount  that  Is  to  be 
added  or  subtracted  from  the  previous  absolute 
coordinate  point. 

VRX  • vector  relative  auto-increment  x;  each  draw 

Instruction  causes  the  y and  z coordinate  values 
to  be  incremented  by  the  specified  value  while 
X Is  stepped  by  a constant  value. 

VRY  - vector  relative  auto-increment  yl  each  draw 

Instruction  causes  the  x and  z coordinate  values 
to  be  incremented  bv  the  specified  value  while 
y Is  stepped  by  a constant  value. 

VRZ  - vector  relative  auto-l nc rement  z!  each  draw 

Instruction  causas  the  x and  y coordinate  values 
to  ba  Incremented  by  the  specified  yalue  while 
z Is  stepped  by  a constant  value. 


TABLE  A-I 
(cont  < nued) 


INC2*>  t wo*d< mens i ona  1 incremental  vector;  a 

relative  vector  that  optimizes  storage  re** 
quirements.  The  coordinate  increment  values 
are  limited  to  values  approximately  3X  of  the 
user's  coordinate  range. 
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INCX*  two-dimensional  incremental  auto-increment  x; 
is  a relative  vector  that  optimizes  storage 
requirements.  The  y coordinate  value  is 
incremented  by  a small  value  while 
X is  stepped  by  a constant  value. 
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INCY-  two-dimensional  incremental  auto-increment  y; 


is  a relative  vector  that  optimizes  storage 
requirements.  The  x coordinate  value  is 
incremented  by  a small  value  while 
y is  stepped  by  a constant  value. 

INC3-  three-dimensional  incremental  vector;  a 

relative  vector  that  ootimiz'es  storage  re- 
quirements. The  x»  v»  z coordinate  increment 
are  limited  to  values  that  are  approximately 
of  the  user's  coordinate  range. 


A nor*  d«t«n«d  account  of  each  vector  tyoe  and  the 
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paranetera  required  by  setvector  are  listed  in  Appendix  B. 
Figure  A-a  illustrates  the  five  different  vector  modes  that 

are  avai 1 abl e. 


VECTOR  MODE 
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Vector  Modes 
FIGURE  A-4 


b.  Move 

The  draw  instruction  move  is  used  to  reposition 
the  beam  on  the  display  screen.  It  will  produce  no  visible 
line  or  pattern.  The  format  of  the  instruction  is: 


move (x  (fvl  IfZl); 


The  coordinate  values 

X » y « 

z will 

be 

either  absolute 

or 

rel at { ve 

values. 

The 

vector 

tyoe 

selected 

i n 

the 

precaedi ng 

setvector 

instruct  ion 

wi  1 1 

determine 

how 

thf 

value  of  these  parameters  will  be  interpreted. 
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A mov*  instruction  under  sn  absolute  vector  type  will 
reposition  the  beam  at  the  absolute  coordinate  given  in  the 
move  instruction  parameter  tist.  Absolute  parameter  values 
which  eiceed  the  limits  of  the  defined  coordinate  system 
will  be  assigned  a value  of  the  nearest  coordinate  within 
the  defined  system. 

A move  instruction  under  a relative  vector  type  will 
reposition  the  beam  at  a location  determined  by  adding  the 
parameter  values  to  the  present  beam  location.  Relative 
parameter  values  which  exceed  one*half  the  coordinate  range 
will  be  set  to  zero. 

The  bracketed  values  indicate  parameters  that  may  be 
optional.  If  the  user  coordinate  system  is  not  three* 
dimensional*  the  z parameter  can  be  omitted*  and  will  be 
ignored  if  it  should  be  included. 

c.  Line 

The  line  instruction  draws  a visible  line  or 
vector  on  the  display  screen.  The  line  is  drawn  from  the 
present  beam  locaton  to  the  specified  end  point.  The  format 
of  the  instruction  is: 

I ine(x  (*  yl  [*  zl  ) * 

The  coordinate  values  x*  v*  z will  be  either  absolute  or 
relative  values.  The  vector  type  selected  in  the  previous 
setvector  determines  how  the  value  of  these  parameters  will 
be  interpreted. 

A line  instruction  under  an  absolute  vector  type  will 
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draw  a lina  from  the  oresent  beam  position  to  the  absolute 
coordinate  specified  in  the  line  instruction  parameter  list. 
Absolute  parameter  values  which  exceed  the  limits  of  the 
defined  coordinate  system  will  be  assigned  a value  of  the 
nearest  coordinate  within  the  defined  system. 

A line  instruction  under  a relative  vector  type  will 
draw  a line  from  the  present  beam  position  to  a point 
determined  by  addino  the  parameter  values  to  the  present 
beam  location.  Relative  parameter  values  which  exceed  one- 
half  the  coordinate  range  will  be  set  to  zero. 

If  the  user  has  defined  a two-dimensional  coordinate 
system.  the  z oarameter  can  be  omitted,  and  will  be  ignored 
if  it  should  be  included. 

d.  Circle 

The  circle  instruction  will  draw  a circle 
beginning  at  the  present  beam  location  about  the  center 
point  specified  by  the  user.  The  difference  between  the 
oresent  beam  location  and  the  center  point  determines  the 
radius  of  the  circle.  The  instruction  is  used  by  the 
f o 1 lowing  format : 

ci re  I e(di r.cent X I.centy)  I.centz)); 

The  parameter  dir  indicates  in  which  direction  the 
circle  is  to  be  drawn,  clockwise  or  counterclockwise.  The 
number  of  parameters  required  and  their  values  are 
determined  by  the  vector  type  selected  in  the  previous 
setvector  instruction. 
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Circle  commands  issued  under  absolute  vector  tyoes  will 
cause  the  circle  to  be  drawn  about  a center  point  as 
specified  in  the  parameter  list.  Absolute  parameters  which 
exceed  the  limits  of  the  defined  coordinate  system  will 
assume  a value  of  the  nearest  coordinate  within  the  defined 
system. 

Circle  commands  issued  under  relative  vector  types  will 
cause  the  circle  to  be  drawn  about  a center  point  determined 
by  adding  the  parameter  values  to  the  present  beam  location. 
Relative  parameter  values  which  exceed  one*half  the 
coordinate  range  will  be  set  to  zero. 

If  the  user  coordinate  system  is  two-di mensi onal » the  z 
parameter  can  be  omitted^  and  will  be  ignored  if  included.  A 
circle  cannot  be  drawn  by  any  of  the  four  incremental 
vectors. 

e.  Arc 

The  arc  instruction  will  draw  an  arc  from  the 
present  beam  location#  about  the  specified  center  point#  to 
the  desired  end  point.  The  distance  between  the  starting 
point  and  the  canter  point  determines  the  radius  of  the  arc 
being  drawn.  The  instruction  format  is  : 

arc (di r#centx  [#centy]  ( # cent z) # endx  (#endy]  (#endz))# 

The  parameter  dir#  gives  the  direction  the  arc  is  to  be 
drawn#  clockwise  or  counterclockwise.  The  arc's  actual 
center  and  end  points  are  determined  by  the  vector  tyoe 
selected  in  the  previous  call  to  setvector#  and  by  the 
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supplied  parameter  values. 

Arc  commands  issued  under  absolute  vector  types  will 
result  in  the  center  and  end  points  being  absolute 
coordinates  as  given  in  the  command  parameter  list. 
Absolute  parameters  which  exceed  the  limits  of  the  defined 
coordinate  system  will  assume  a value  of  the  nearest 
coordinate  within  the  defined  system. 

Arc  commands  issued  under  relative  vector  tyoes  will 
result  in  the  end  point  of  the  arc  being  determined  by 
adding  the  endx«  endy,  and  endz  values  to  the  present  beam 
location.  The  center  point  is  then  obtained  by  adding  the 
centXf  centy,  and  centz  values  to  the  end  point.  Relative 
parameters  which  exceed  one-half  the  coordinate  range  will 
be  set  to  zero. 

If  the  user  coordinate  system  has  been  defined  as  two- 
dimensional*  the  z parameters  can  be  omitted*  and  will  be 
ignored  if  included.  An  arc  cannot  be  drawn  by  any  of  the 
four  incremental  vectors. 

If  the  distance  from  the  starting  ooint  of  the  arc  to 
the  center  ooint*  and  the  distance  from  the  end  point  to  the 
center  point  are  not  equal*  the  resulting  arc  will  contain  a 
straight  line.  The  straight  line  results  from  the  arc 
generator  trying  to  compensate  for  the  two  different 
distances  to  the  center  point.  One  distance  will  be  used  to 
determine  the  radius  of  the  arc;  the  arc  will  then  be  drawn 
using  this  radius.  The  arc  will  stop  at  the  systems  new 
defined  end  point  And  a straight  line  will  be  drawn  to  the 
end  point  that  had  been  specified  by  the  user.  The  resulting 
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arc  aopaars  in  the  following  form 


2.  Character  Clement 

A character  element  represents  ASCII  character  data  that 
is  to  be  incorporated  into  the  picture  structure.  A user  can 
specify  a character  element  containing  ASCII/  special  Vector 
General  characters  and  formatting  symbols  to  be  displayed  on 
the  Vector  General  display  screen,  A user  can  select  from 
four  character  sizes  and  has  the  option  of  selecting  a 
slanted  character  set.  The  text  can  be  displayed 
horizontally  or  vertically  on  the  screen.  The  vertical 
position  causes  the  characters  to  appear  as  if  they  were  on 
a page  that  had  been  rotated  ninety  degrees  counter 
clocicwise.  The  user  can  select  the  position  on  the  screen 
where  the  string  is  to  begin/  or  can  output  it  relative  to 
the  present  beam  position. 

Each  character  element  is  given  a unioue  name  by  the 
user.  This  name  will  allow  the  user  to  easily  reference 
each  character  element.  There  are  two  routines  which  can 
produce  character  element  strings. 

a.  Charele 

The  charele  instruction  produces  a character 
element  string  of  a given  length.  The  charele  character 
element  generally  reouires  less  display  list  space  than  the 
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printv  character  element  and  is  designed  for  elements  which 
do  not  change.  The  character  element  is  represented  by  the 
following  format : 

chare1e("el emen t -name" »string»si2e»wdir»s1ant»x»y); 

The  parameter  string  can  be  either  a quoted  string 
within  the  parameter  list  or  a pointer  to  a character  string 
or  array.  The  character  string  will  begin  at  the  point(x,y) 
or  can  be  output  relative  to  the  present  beam  location  by 
replacing  the  x and  y parameter  with  the  constant  VGREL. 
For  example,  the  following  character  element,  when  linked  to 
an  object,  would  be  output  relative  to  the  present  beam 
pos i t i on : 

I charel e ( "e 1 ement -name" . "Now  is  the  t i me" . 3Z^ . HOR . SLMT . VGREL ) J 

A summary  of  the  character  element  parameters  is 

I presented  in  Table  A-II.  The  character  set  available  on  the 

^ Vector  General  is  illustrated  in  Figure  A-5.  All  of  the 

Vector  General  characters  can  be  represented  within  a 
character  string.  The  special  formatting  symbols  and 

special  Vector  General  characters  are  listed  in  Appendix  B. 
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table  a-ii 


summary  of  character  element  parameters 

size:  specify  character  size 

SZ  / 00  - use  previously  defined  character  size 

SZl  / 0100  “ set  size  to  100  columns  by  60  lines 

SZ2  / 0120  - set  size  to  81  columns  by  41  lines 

SZ3  / 0140  - set  size  to  60  columns  by  30  lines 

SZ4  / 0160  - set  size  to  32  columns  by  16  lines 

wdir;  write  direction 

HOR  / 00  - write  characters  horizontally 

VER  / 0200  - write  characters  vertically 


slant:  specifies  regular  or  slanted  characters 

SLNT  / 00  • slanted  characters 
NSLNT/  01  - regular  characters 
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b*  Printv 


The  orintv  instruction  provides  for  a formatted 
output  character  element  string  of  variable  length.  Maximum 
character  length  for  a orintv  character  element  string  is 
100  characters.  The  printv  character  element  is  designed 
for  output  character  strings  which  change  frequently.  The 
printv  character  element  is  represented  by  the  following 
format : 

printv("el ename" » si ze»wdir»slant»xpos»ypos»"format" 

( .arqlfarg2> »argl0  1 ); 

The  first  six  parameters  are  identical  in  use  to  the 
charele  format  in  initializing  and  oositioning  the  character 
string.  The  orintv  character  string  cannot^  however.  be 
positioned  relatively  but  must  be  supolied  with  both  X and  Y 
absolute  coordinates.  The  format  parameter  and  ten  optional 
arg  parameters  are  used  as  in  a standard  printf  statement  in 
formatting  output. 

An  example  of  the  use  of  the  orintv  character  element 
would  be  as  follows: 

printv("RESULT",SZa.HOR,SLNT,5.0.0.0,  "resul  t = Sid". 

resul t ) ; 

and  could  be  changed  later  in  the  program  to: 

orintv("ReSULT".SZ3.H0R.N8LNT.-10,0. 15,0."score  = Xd". 

score) ; 


C.  LINKING  ELEMENTS  TO  OBJECTS 


Draw  and  character  elements  represent  the  smallest 
picture  segment  that  can  be  independently  referenced  by  the 
user.  In  order  to  display  an  element  it  must  be  associated 
with  at  least  one  object.  An  object  represents  the  smallest 
entity  that  can  be  displayed  independently  on  the  Vector 
General  screen. 

1.  Object  Routine 

Each  object  is  given  a unique  name  so  it  can  be 
easily  referenced  by  the  user.  Elements  can  be  linked  to  an 
object  at  one  time  or  by  several  different  calls  to  the 
routine  called  object.  An  object  can  consist  of  one  or  more 
elements.  A specific  element  can  be  linked  to  several 
different  objects^  or  may  be  linked  to  one  object  several 
times.  This  ob j ect*el ement  association  or  linking  is 
established  by  the  routine  object.  This  routine  has  the 
following  format : 

ob j ect (num» "ob j ec t -name" » "el ement-name" » ...» "el ement -name" ) ! 

The  parameter  num  indicates  the  number  of  elements  that 
are  to  be  linked  to  the  named  object  by  this  call.  The 
elements  are  referenced  by  the  names  specified  by  the  user 
in  the  preceding  draweler  charele»  and  orintv  routines. 
Since  each  object  is  associated  with  a unique  name»  a second 
call  to  objectf  with  a duplicated  object  name»  will  cause 
the  elements  to  be  added  to  the  object  first  associated  with 
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that  name 


Mhen  an  element  is  linked  to  a specific  object  several 


t i mes 


the  user  can  no  longer  reference  a specific 


occurrence  of  this  element  within  the  objects  for  example 


obiect(3»"Tree"f"branch"» "branch " i "branch"  ) ; 


In  this  case  the  element  branch  has  been  linked  to  the 


object  tree  three  times.  When  displayed^  element  branch 


will  appear  three  times 


however^  the  user  cannot 


uniquely  reference  a specific  occurrence  of  the  element 


branch.  If  the  element  called  branch  was  selected  to  be 


erased^  the  first  occurrence  of  branch  would  be  erased  from 


the  screen.  In  many  instances  it  may  be  desirable  to 


uniquely  reference  each  occurrence  of  an  element  within  a 


specific  object.  This  can  be  accomplished  by  associating 


several  unique  names  with  an  element.  The  routine  copyele 


provides  this  capability 


i,  Copyele  Routine 


This  routine  allows  a user  to  assign  several  unique 


names  to  a specific  element  structure.  In  this  way«  an 


element  structure  can  be  associated  with  an  object  several 


times  and  each  occurrence  can  be  uniauelv  referenced.  The 


routine  is  represented  by  the  following  format 


copy el e (num^ "el ement -name" » "cooyl-name"f "copy 2 -name 


The  parameter  num  indicates  the  number  of  additional  names  a 
user  wishes  to  associate  with  the  named  element  structure. 
The  "e I ement *name"  refers  to  a previously  defined  draw 
element  or  character  element  block.  Each  of  the  "copy- 
names"  must  be  unique. 

Now  reconsider  the  previous  example.  If  the  element 
branch  is  associatea  with  two  other  unique  names  and  these 
three  names  are  used  in  the  object-element  linking^  each 
occurrence  of  the  structure  can  now  be  uniquely  referenced 
by  the  user.  The  following  two  statements  will  accomplish 
this  task. 

copy  el  e (2»  "branch" » "branch  *’branch2"  ) ; 
object(3/"tree"»"branch"»"branchl"»"branch2")» 
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V.  USER  SUPPORT  ROUTINES 


After  the  user  has  incorporated  all  data  that  is  to  be 
displayed  into  the  desired  picture  structure#  it  can  now  be 
manipulated  and  transformed.  The  following  user  routines 
provide  the  means  to  manipulate  the  picture#  objects  and 
elements  that  have  been  created  by  the  user. 

A description  of  each  user  routine#  calling  format  and 
error  diagnostics  are  included  in  Appendix  B. 

A.  PICTURE  REPRESENTATION 

1.  Blink 

The  display  blink  mode  can  be  set  for  the  entire 
picture#  single  object  or  for  any  number  of  elements 
associated  with  a specific  object.  Modifying  the  blink  mode 
of  an  object  affects  all  the  elements  associated  with  that 
object.  The  routine  blink  will  turn  the  blink  mode  on  or 
off  for  the  specified  picture  segment. 

2.  Erase 

The  entire  picture#  a single  object  or  any  number  of 
elements  associated  with  a specific  object  can  be  erased 
from  the  display  screen.  The  Picture  segments  that  are 
erased  from  the  screen  can  be  redisplayed  by  again 
establishing  the  desired  object'el ement  association.  This  is 
accomplished  by  calling  the  routine  object#  as  described 
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earlier.  Erasing  an  object  will  affect  all  elements 
associated  with  the  named  object. 

3.  Remove 

The  routine  remove  provides  a user  with  the  ability 
to  release  the  memory  locations  associated  with  a specific 
element  structure.  The  user  can  remove  the  picture  and 
release  all  the  memory  locations  that  have  been  used  to 
describe  all  the  existing  elements.  Additionally  the  picture 
will  be  erased  from  the  screen.  Each  element  that  is  removed 
from  memory  can  no  longer  be  referenced  or  linked  to 
objects.  An  individual  element  can  also  be  removed  from 
memory.  This  will  cause  every  occurrence  of  the  element  to 
be  erased  from  the  screen  and  the  memory  locations 
associated  with  the  element's  description  will  be  released. 
The  user  can  specify  an  element  for  removal  by  either  its 
original  name  or  by  any  of  the  copy  names  associated  with 
it.  Remove  results  in  the  elimination  of  all  occurrences  and 
alt  copies  of  an  element  from  the  display  screen.  An 
element  that  has  been  removed  can  be  redisplayed  only  oy 
reconst ruct i ng  the  element  block  and  by  again  establishing 
the  desired  object-element  association. 

4.  Display 

The  display  of  the  entire  picture^  an  object*  or 
individual  elements  may  be  activated  or  deactivated  with 
this  routine.  Object-element  associations  are  not  affected 
with  this  routine  as  they  are  with  erase  and  remove. 
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5.  Refresh 

The  default  display  refresh  rate  is  40  Hz  and  may  be 
altered  from  15  to  120  Hz  with  this  routine.  High  refresh 
rates  ensure  no  flicker  but  may  not  allow  enough  time  to 
execute  all  desired  draw  commands  before  refresh  begins 
again.  Low  refresh  rates  allow  more  draw  commands  but  with 
an  increase  in  flicker. 


6.  Offset 

Picture  coordinate  axis  positioning  is  normally 
centered  on  the  display  screen  but  may  be  altered  with  this 
routine.  Altering  of  the  picture  coordinate  axis  will 
affect  all  objects  in  the  picture. 
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7.  Pscale 

Modification  of  the  picture  scale  may  be 
accomplished  by  calling  this  routine.  All  objects  within 
the  display  are  affected  by  a modification  with  this 
rout i ne . 

8.  Intensity  Offset 

The  routine  intoffset  allows  the  user  to  vary  the 
intensity  lev.  'I  of  a three-dimensional  objects  or  impose  a 
screen  cut-off  plane  for  the  named  object. 

R.  Intensity  Scale 

The  routine  intscale  allows  a user  to  vary  the 
intensity  of  a three-dimensional  object.  This  provides  the 
depth-cueing  or  shading  for  a three-dimensional  object. 
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B.  PICTURE  MANIPULATION 


1.  Rotate 

This  routine  allows  a user  to  rotate  an  object  about 
the  X#  Vf  and  z axis.  The  rotation  of  an  object  affects  all 
elements  associated  with  the  named  object.  Arcs#  circles 
and  characters  are  always  drawn  in  a plane  parallel  to  the 
screen#  and  are  rotatable  in  a three-dimensional  coordinate 
system  about  the  z-axis. 

i.  Scale 

The  routine  scale  allows  a user  to  independently 
scale  any  object  of  the  picture.  All  elements  associated 
with  the  object  will  be  scaled  by  the  specified  scale 
factor. 

3.  Translate 

The  routine  trans  allows  the  user  to  move  an  object 
anywhere  in  the  display  space.  The  object  and  all  its 
associated  elements  can  be  moved  in  the  x#  y#  and  z planes. 
Continually  translating  an  object  by  very  small  increments 
will  cause  it  to  appear  as  if  it  is  moving  across  the 
display  screen. 

4.  Place 

The  place  routine  allows  the  user  to  place  or 
position  an  object  anywhere  in  the  display  space. 
Specification  of  an  absolute  coordinate  value  will  cause  the 
coordinate  axes  of  the  object  to  be  centered  on  the 
specified  value. 


C.  EXTERNAL  DEVICES 


1,  Cursor 

This  routine  allows  the  user  the  option  of 
activating  or  deactivating  the  display  of  the  trackball/ 
joystick#  or  lightpen  cursor, 

2,  Posit 

This  routine  will  return  to  the  user  a floating 
point  value  of  the  position  of  the  trackball#  joystick#  or 
lightoen  cursor.  The  cursor  need  not  be  displayed  for  this 
routine  to  work, 

3,  Keyboard 

a.  Cget 

The  routine  cget  allows  a user  to  receive  and 
output  characters  from  the  Vector  General  keyboard  onto  the 
display  screen.  The  ASCII  character  data  is  also  placed  in 
a user  specified  character  array  for  processing  by  the 
user's  program.  Up  to  121  characters  can  be  entered.  Data 
entry  is  terminated  by  a carriage  return.  The  termination 
of  the  data  entry  also  erases  the  output  characters  from  the 
display  screen. 

b.  Fget 

The  fget  routine  returns  to  the  user  a floating 
point  number  entered  from  the  Vector  General  keyboard.  This 
routine  uses  both  the  cget  and  getf  routines. 
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c.  Iget 

The  iget  routine  returns  to  the  user  an  integer 
entered  from  the  Vector  General  keyboard*  This  routine  uses 
both  the  cget  and  geti  routines. 

4.  Lightpen 

a.  Lghtpen 

The  lightpen  se1 ectabi 1 i ty  of  the  picture#  a 
single  object#  or  any  number  of  elements  associated  with  a 
specific  object  can  be  turned  on  or  off  by  this  routine. 
This  determines  what  picture  segments  will  be  affected  by 
lightpen  interactions. 

b.  Penhit 

After  an  element's  lightpen  sel ectabi 1 i ty  has 
been  activated  with  the  lghtpen  routine#  determination  of 
whether  or  not  an  element  has  registered  a lightpen  hit  is 
accomplished  with  this  routine.  A one  is  returned  if  a 
lightoen  hit  has  occurred;  otherwise  a zero  is  returned. 

For  an  element  to  register  a lightpen  hit  it  is 
necessary  not  only  for  the  element's  lightoen  sel ectabi 1 i ty 
to  have  been  activated#  but  also  the  lightpen  must  be 
pointing  at  the  element  and  the  lightoen  sense  switch  must 
be  activated.  The  lightoen  sense  switch  is  activated  bv 
bridging  the  small  rubber  gap  on  the  forward  part  of  the 
1 ightpcn. 


94 


C 1 Ph  i t 


c . 

This  routine  is  used  to  clear  the  elements  of 
Hghtoen  hits.  Element  lightoen  sel  ectabi  1 i tv  is  unaffected 
by  this  routine. 

5.  Function  Switches 


a.  Fsman 

This  routine  returns  to  the  user  an  indication 
of  whether  or  not  a specified  function  switch  is  depressed. 
A one  is  returned  to  the  user  if  deoressed*  otherwise  a zero 
i f returned. 

b.  Fstog 

This  routine  makes  the  function  switches  appear 
as  toggle  switches.  Odd  ( 1 st . 3rdr . . . ) selections  of  a 
switch  light  the  lamp  and  return  a value  of  one.  Even 
( 2nd7 4t h # . . . ) selections  turn  the  lamp  off  and  return  a 
value  of  zero. 


c.  Lamp 

The  lamp  routine  will  light  or  extinguish  the 
specified  function  switch  lamp. 


d.  Manint 

Each  depression  of  the  manual  interrupt  function 
switch  increments  the  manual  interrupt  count  by  one.  The 
manint  routine  either  returns  to  the  user  the  present  manual 
interrupt  count  or  sets  that  count  to  zero. 
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6.  Control  Dials 

The  dial  routine  returns  a floating  point  number  from 
•1.0  to  1.0  to  the  user  to  indicate  the  relative  position  of 
the  specified  control  dial. 
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VI.  RUNNING  A VECTOR  GENERAL  PROGRAM 

A.  PROGRAM  FORMAT  AND  COMPILATION 

In  order  to  prooerly  utfHze  the  Vector  General  display 
systeer  routines  to  initialize  and  terminate  the  system  must 
be  called.  These  routines  initialize  the  Vector  Generair 
start  the  actual  visual  display  and  properly  terminate  the 
display  at  the  end  of  a user's  program.  Each  user  program 
must  include  a call  to  these  three  routines: 

sysi ni t ( ) ? 
vgpicturel ) ; 
vgtermi ) ; 

The  first  routine#  sysinit#  must  be  called  by  the  user 
before  any  other  user  interface  routine  is  called.  To 
display  the  picture  that  a user  has  described  on  the  Vector 
General  screen#  the  routine  vgpicture  must  be  called.  This 
routine  is  called  only  once#  and  nothing  will  appear  on  the 
screen  until  it  has  been  called.  Finally#  to  properly 
terminate#  the  system  reauires  a call  to  the  routine  vqterm 
at  the  end  of  the  user  program. 

1.  C Programs 

To  properly  initialize  various  data  structures  in 
the  interface  routines  and  utilize  the  Vector  General 
program  constants  used  in  this  manual  the  first  line  in  the 
user's  program  should  bet 
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•include  "/uer/graph/vgdata" 


Once  a C program  has  been  written  it  must  be  compiled 
with  the  user  interface  graphics  subroutine  library.  To 
accomplish  this  the  following  command  must  be  issued: 

vgc  filename.c 

The  result  of  a successful  compilation  is  an  eaecutable 
a, out  file, 

2,  Basic  Programs 

The  first  subroutine  call  made  by  the  BASIC  program 
should  be: 

call  vgdat a ( ) ' 

This  causes  the  loading  of  the  initialized  display  list. 
Care  must  be  made  in  previously  declaring  the  "vgdata"  call 
in  an  "extern"  statement  before  this  call.  This  call  would 
be  in  lieu  of  the  "include"  statement  used  by  the  C 
programs , 

The  program  constant  names  used  in  the  C Vector  General 
programs  do  not  apply  in  BASIC  Vector  General  programs. 
Conversion  values  must  be  utilized  instead  of  the  string 
constant  names  when  programming  in  BASIC,  The  following 
table  lists  the  constant  names  and  the  eauivalent  values  in 
decimal  number  representat ion  to  be  used: 

OCFINE  VECTOR  TYPES 

VAY  s 4102 
VAZ  s 4103 
INC2  a ai04 


VR  a 4096 
VRX  a 4097 
VRY  a 4098 
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VRZ 

= a099 

INCX  z 4105 

VA 

z aioo 

INCY  z 4106 

VAX 

a aioi 

INC3  z 4107 

DEFINE 

VECTOR  MODES 

LN 

z 0 

PT  z 40 

OSH 

* 16 

00  z 80 

DOT 

Z 32 

ODD  z 96 

define 

COORDINATE  FIELD  VALUES 

AIR 

z 0 

X z 0 

XR 

z 1 

Y z 1 

YR 

Z 2 

Z z 2 

ZR 

Z 3 

DEFINE 

OF  AND  CF  FIELDS  FOR  ARC  COMMANDS 

C s 

; 4 

CC  = 

: 8 

define 

FIELDS  FOR  INCREMENTAL  VECTORS 

INCREMENT  SCALE 

NHG 

z 0.0 

MG 

z 120.0 

DEFINE 

CONSTANTS  FOR  CHARACTER  GENERATION 

SLNT 

z 0 

VGREL  z -.00001 

NSLNT  s 1 

CHARACTER  HRITE  DIRECTION 

HOR 

z 0 

VER 

z 128 

CHARACTER  SIZE 

SZ 

z 0 

SZ3  z 96 

SZl 

z 64 

SZ4  z 112 

SZZ 

z 00 

DEFINE 

ACTION  parameter 

ON 

z 1 

CLEAR  r 0 

OFF 

z 0 

COUNT  z 1 

DEFINE 

CASE  STATEMENT  VALUES  FOR  OBJ-ELE- 

PIC 

z 0 

ELE  z 1 

OBJ 

z •! 

DEFINE 

DEVICE  SNITCH  NUMBERS 

LPEN 

1 z 0 

JOY  z 2 

TRK 

z 1 

One*  a BASIC  orogran  has  been  Mritten#  it  must  be 
4 compiled  with  the  various  user  subroutine  libraries.  To 

i 

r 

(accomplish  the  task#  the  following  system  resident  command 
must  be  issued: 


I 


vgb  f i 1 ename.b 

The  result  of  a successful  compilation  is  an  eKSCutable 
"a.out”  file. 
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B.  sample  programs 


1 


1.  C Programs 

The  folloMfng  Is  an  axamote  of  a C'language  Vector 
General  graohics  orogram.  The  actual  oicture  produced  by 
this  program  is  illustrated  in  Figure  A-6. 


Ainclude  "/usr/graph/vgdata" 

mainO 

{ 

i nt  i ; 

svsinit(O);  //initialize  the  Vector  General 

//define  coordinate  system 
coordsysCZfl.O^l. 0^*1. 0(1.0); 

drawele("bo*") t 

setvector  (VArLiV) ; 

move(-l .0»-l .0) ; 

1ine(  l.O(-l.O); 
line(  1.0(  1.0); 
line(*1.0(  1.0); 
line(«1.0»-1.0); 
endel e ( ) ; 

charele("name"("<»I  80X",SZa(H0R,NSLNT,VGREL); 

draweleC "zigzag") ; 

setvector (VA,LN) ; 

move(-0.5»-0.5) ; 
setvector ( INCX(LN( .03(NMG) ; 
for ( i *0  ; i < 7 ; i ♦♦  ) 

1 ine(.03(-.03); 
endel e( ) t 

//establish  ob ject>element  relationship 
object ( 3» "bi gbo«" » "bo*" » "name" » "z i gzag" ) ! 
object (3( "smal 1 box" » "box" » "name" ("zigzag"); 

seal e("bi gbox"( 0.5) ; 
trans("bigbox"(-0,5(-0.5) ; 
seal e( "smsi 1 bos" ( 0 .25) ; 
trans("smal lbos"(0.5(0.5); 

vgpictureO;  //display  picture 
s1eep(30);  //display  picture  for  30  sec 
vgtermi);  //terminate  Vector  General  process 

) 
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2,  Basic  Program 

The  folloMing  is  an  example  of  a BASIC  Vector  General 
graphics  program.  The  actual  picture  produced  by  this 
program  is  illustrated  in  Figure  A-6. 


rem  external  subroutine  declarations 
extern  vgdataO 
extern  svsi n i t ( i nteger ) 

extern  coordsys ( i nteger > doub I e^ doub I e r doub I e^doub I e) 
extern  drawele(&char) 

extern  set  vector! integer^ i nteger » doub I e»doub1 e ) 
extern  move(doubl e^double) 
extern  I i ne (doubi e# doubi e ) 
extern  endele!) 

extern  charele(&char«&char»i nteger  ^ i nteger* i nteger  * doub I e ) 

extern  object ( i nt eaer * &char * &char * &char * &char ) 

extern  seal e(&char*doubl e) 

extern  t rans (&char *doubl e* doub I e ) 

extern  vgpictureO 

extern  sleep! integer) 

extern  vgterm!) 

rem  initialize  display  list 

cal  I vgdata! ) 

rem  initialize  the  Vector  General 

call  sysi ni t !0 ) 

rem  define  coordinate  system 

cal  I coo rdsys!2**t. 0*1. 0*«1. 0*1.0) 

cal?  drawele!”box*) 

call  setvector!4l00*0*0*0) 

call  move!*! .0*-! .0) 

cal  I I ine! 1 .0**1 .0) 

cal  I I ine! 1 .0* 1 .0) 

cal  1 1 i ne!*l .0* 1 .0) 

cal  1 I ine!*l .0»-l .0) 

call  endele!) 

call  chare) a! "name" * "si  BOX"* 1 12*0* 1 **.00001 ) 

call  drawele!"zigzag") 

call  setvector!4i00*0*0*0) 
call  move!*0. 2*0.0) 
cal)  setvector!4i05*0*.03*0) 
for  i s 0 to  6 

call  line! .03**. 03) 
next  i 

call  endele!) 

re«  establish  ob j act *e lament  relationship 
call  Ob j ec t ! 3* "bigbox"* "box"* "name"# "zigzag") 
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c«n  Ob  ject  (3»  "smal  >boi«"»  "bo*"#  "name"f  "zigzag") 


call  seale(*b1gbox">0.5) 
call  trana("blgbo«"»-0,5»-0,5) 
call  seal e( "smal I box " » 0 .25) 
call  trana("smal Ibox"r0.5»0.5) 

ram  display  picture 

cal  I vgpicture( ) 

rem  display  picture  for  30  sec 

call  si eep( 30) 

rem  terminate  Vector  General  process 

cal  I vgterm( ) 
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C.  ERROR  DIAGNOSTICS 

A user  can  control  the  printing  of  error  messages 
through  the  use  of  the  errormsg  routine.  The  general  format 
of  an  error  message  wilt  be  as  follows: 

E*nn  TTTT:  "eeee"  in  routine  rrrr() 
where: 


nn  s 

error  number 

TTTT 

s 

error  type 

eeee 

s 

error 

r r rr 

s 

routine  in  error 

For  example: 

1.  E«1  BLOCK:  in  routine  line() 

Message  Indicates  a block  error  in  routine 
lineC).  Probable  cause  is  a line()  command  issued 
outside  a drawele()  block.  The  line()  command  will 
be  disregarded  and  control  returned  to  the  user's 
program. 

2.  E-5  NO  OBJ:  "Tree"  in  routine  erase!) 

Message  indicates  that  the  object  'Tree'  has 
been  used  in  the  erase!)  routine  and  no  such  object 
currently  exists.  Routine  will  be  disregarded  and 
control  returned  to  the  user's  program. 

3.  E-15  X:  "150.000000"  in  routine  printv!) 

Message  indicates  an  improper  X coordinate 
value  in  the  printv!)  routine.  The  erroneous  x 
coordinate  value  of  150  will  be  reduced  to  a value 
within  the  defined  coordinate  system  !ie:  100  for 
default  coordinate  system)  and  the  routine  will 
continue  execution. 

a.  E-25  NUM  dial:  "36"  in  routine  dial!) 

Message  indicates  an  improper  dial  number 
of  36  used  in  the  dial!)  routine.  Routine  will 
return  a value  of  0.0  to  the  user. 

A brief  idea  of  the  cause  of  the  error  may  be  gained 
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from  the  error  tyoe  specification  in  the  error  message. 
Hopefully  with  a specification  of  the  error»  the  error  type 
and  routine  where  the  error  occured.  the  user  will  be  able 
to  Quickly  trace  and  correct  the  oroblem.  Should  a more 
detailed  enplanation  be  desiredr  a fuller  description  of  the 
specified  error  may  be  obtained  with  the  help  of  the  error 
number  and  error  diagnostic  table#  or  by  reviewing  the 
diagnostic  section  under  the  routine  in  question. 

The  software  support  oackaga  is  designed  so  that  most 
errors  will  not  terminate  a user's  program,  and  in  fact  most 
errors  will  usually  result  in  the  termination  of  the 
specified  routine  and  return  control  to  the  user's  program. 
Every  effort  will  be  made  to  execute  the  support  routines 
and  user's  program  to  completion  so  that  at  least  some  of 
the  user's  data  will  be  displayed. 


TABLE-III 

ERROR  DIAGNOSTIC  TABLE 

E-l  ELEMENT  BLOCK  ERROR  • The  specified  routine  is  in 

error  in  one  of  two  respects.  Either  the  routine 
has  been  called  outside  a drawelel)  block  when  it 
should  be  within,  or  the  routine  has  been  called 
within  a drawelel)  block  when  it  should  be 
outside.  The  instruction  will  be  ignored  and 
control  returned  to  the  user's  program.  Block 
errors  have  a tendency  to  occur  in  groups  when  the 
programmer  is  not  careful  in  constructing  element 
blocks. 

E-2  SPACE  ERROR  - Space  allocated  by  the  system  for 

the  building  of  elements  has  been  exceeded.  See 
the  routine  remove  in  order  to  free  uo  unnecessary 
element  memory  locations.  The  instruction 
executing  when  this  error  occurs  will  be  ignored 
and  control  will  be  returned  to  the  user's 
program. 

E-3  DIRECTION  ERROR  - The  value  of  the  parameter  'dir' 


105 


was  not  C or  CC  in  the  specified  routine.  A 
direction  of  C will  be  assumed  and  the  routine 
will  continue  execution. 

CHARACTER  ERROR  - A character  symbol  included  in 
an  ASCII  character  string  is  undefined.  The 
symbol  will  be  ignored  and  control  will  be 
returned  to  the  user's  program. 

OBJECT  ERROR  - The  named  object  does  not  exist?  it 
has  not  been  defined  in  a call  to  the  routine 
objecti).  A specification  of  a non-existent 
object  will  terminate  the  routine  and  return 
control  to  the  user's  program. 

ELEMENT  ERROR  - The  named  element  does  not  exist? 
it  has  not  been  defined  in  a call  to  drawe1e()r 
chare1e()»  or  printv().  For  routines  that  specify 
a number  of  element  names#  this  type  of  error 
normally  results  in  skipping  the  specified  element 
and  continuing  the  routine  with  the  next  element. 

DUPLICATE  ELEMENT  ERROR  - An  element  name  has  been 
duplicated  in  a draweleO  or  chareleO  call.  Each 
element  structure  created  by  draweleC)  or 
ChareleO  must  have  a unioue  name.  This  error 
usually  results  in  either  skipping  the  designated 
element  and  continuing  the  routine#  or  termination 
of  the  routine  and  return  to  the  user's  program. 

ELEMENT  NUMBER  ERROR  -The  total  number  of  elements 
allowed  by  the  system  has  been  exceeded.  Maximum 
number  of  elements  allowed  is  70.  The  user  should 
consider  using  the  removed  routine  to  delete 
unnecessary  elements  so  new  elements  may  be 
i nt  reduced. 

OBJECT  NUMBER  ERROR  - The  number  of  objects  allow- 
ed by  the  system  has  been  exceeded.  Maximum 
number  of  objects  is  10. 

VECTOR  MODE  ERROR  - Specified  vector  vmode  in 
setvectorO  routine  is  in  error.  A vector  mode  of 
LN  will  be  assumed  and  the  routine  will  continue 
execution.  See  the  setvector()  summary  for 
allowable  vector  mode  codes. 

DIMENSION  ERROR  - The  coordinate  dimension  speci- 
fication is  in  error.  Either  the  'dim'  parameter 
in  coordsysf)  is  in  error#  or  a vector  type  of  VAZ 
or  VRZ  has  been  specified  with  e two-dimensional 
coordinate  system.  The  routine  in  guestion  will 
be  skipped  and  control  returned  to  the  user's 
program. 
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E-12 

E-13 

E-ia 

E-15 

E-16 

E-17 

E-18 

E-l<> 

E-20 


ADD  element  error  -An  error  has  occurred  in  cget() 
or  objectC)  in  attemoting  to  build  a new  element. 
Routine  terminates  and  control  is  returned  to  the 
user's  program. 

MAKE  OBJECT  ERROR  - An  error  has  occurred  in 
cget()  or  objectC)  in  attempting  to  build  a new 
object.  Routine  terminates  and  control  is 
returned  to  the  user's  program. 

VECTOR  TYPE  ERROR  - An  improper  vector  type  was 
specified  in  routine  setvector ( ) . ' A vector  type 
of  VA  will  be  assumed  and  the  routine  will 
continue  executing.  See  the  setvectorO  summary 
for  allowable  vector  type  codes. 

X COOROINATE/INCREMENT  ERROR  - The  specified  x 
parameter  exceeds  allowable  limits.  If  an 
absolute  x coordinate  exceeds  the  defined 
coordinate  system,  the  x value  will  be  set  to  the 
value  of  the  nearest  coordinate  within  the  defined 
system  (xmin  or  xmax).  If  the  parameter  specifies 
an  X increment  which  exceeds  one-half  the 
coordinate  ranges  the  parameter  is  set  to  zero. 

Y COOROINATE/INCREMENT  ERROR  - The  specified  y 
parameter  exceeds  allowable  limits.  If  an 
absolute  y coordinate  exceeds  the  defined 
coordinate  system,  the  y value  will  be  set  to  the 
value  of  the  nearest  coordinate  within  the  defined 
system  (ymin  or  ymax).  If  the  parameter  specifies 
a y increment  which  exceeds  one-half  the 
coordinate  range,  the  parameter  is  set  to  zero. 

Z COOROINATE/INCREMENT  ERROR  - The  specified  z 
parameter  exceeds  allowable  limits.  If  an 
absolute  z coordinate  exceeos  the  defined 
coordinate  system,  the  z value  will  be  set  to  the 
value  of  the  nearest  coordinate  within  the  defined 
system  (zmin  or  zmax).  If  the  parameter  specifies 
a z increment  which  exceeds  one-half  the 
coordinate  range#  the  parameter  is  set  to  zero. 

ELEMENT  NUMBER  ERROR  - The  parameter  'num'  spe- 
cifying the  number  of  elements  being  passed  in 
this  routine  is  not  -1  to  10.  A 'num'  value  of  10 
will  be  assumed  and  the  routine  will  continue 
execut i ng. 

CIR/ARC  ERROR  - A circle  or  arc  cannot  be  drawn  by 
an  incremental  vector.  The  routine  is  skipped  and 
control  returned  to  the  user's  program. 

USER  BUFFER  ERROR  - The  size  of  the  supplied  user 
buffer  has  been  exceeded.  Either  enter  a carriage 
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return  or  erase  (cntrl-a)  oart  of  the  buffer 


t* 


E-21 

E-22 

E-23 

E-2a 

E-25 

E-26 

E-27 

E-28 

E-29 

E-30 

E-51 


ADO  OBJECT  ERROR  - An  error  has  occurred  in  cget() 
or  objectO  in  attempting  to  add  an  object  to  the 
display.  Routine  terminates  and  control  returned 
to  the  user's  program. 

OBJECT  LINK  ERROR  - The  specified  element  is  not 
linked  to  the  specified  object.  Error  usually 
results  in  skipoing  the  element  in  auestion  and 
continuing  the  routine  with  the  next  element. 

Function  switch  number  error  -An  improper  function 
number  was  specified.  The  routine  terminates  and 
control  is  returned  to  the  user's  program.  A 
value  of  tero  is  returned  to  the  user. 

ACTION  VALUE  ERROR  - An  improper  action  value  was 
specified  in  this  routine.  Refer  to  routine 
summary  diagnostics  for  specific  action  taken. 

DIAL  NUMBER  ERROR  - An  improper  dial  number  was 
specified  in  routine  dial().  The  routine 
terminates  and  a value  of  0.0  is  returned  to  the 
user's  program. 

ELEMENT  ERROR  -Element  specified  in  printv  routine 
was  specified  earlier  as  other  than  a printv 
element.  Routine  will  be  skipped  and  control 
returned  to  the  user's  program. 

DEVICE  NUMBER  ERROR  -An  improper  device  number  was 
used  in  this  routine.  For  sysinitf)  a device 
number  of  zero  will  be  assumed  and  the  routine 
will  continue.  For  cursor!)  or  posit!)  the 
routine  will  terminate  and  control  will  return  to 
the  user's  program.  The  oosit!)  routine  will  also 
return  a value  of  0.0  to  the  user. 

COORDINATE  SPECIFICATION  ERROR  - The  specification 
of  a coordinate  in  this  routine  is  in  error.  The 
routine  terminates  and  a value  of  0.0  is  returned 
to  the  user. 

DIMENSION  ERROR  - Neither  the  lightpen  nor  the 
trackball  have  a z coordinate  specification.  The 
routine  terminates  and  a value  of  O'.O  is  returned 
to  the  user. 

VALUE  ERROR  - The  'val'  parameter  in  intscale!)  or 
intoffset!)^  or  the  'rate'  parameter  in  refresh!) 
is  in  error.  The  rddtine  terminates  and  control 
returns  to  the  user's  program. 

CUT  ERROR  - The  'cut'  parameter  in  intscale!)  is 
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not  zero  op  on«.  The  routine  terminate*  and 
control  returned  to  the  user's  orogram. 


E-32 

E-33 

E-3a 

E-35 

E-36 

E-37 


DUPLICATE  LINK  ERROR  • ''ne  specified  element  is 
*1-  ready  linked  tv  the  object.  The  routine 
continues  execution  uith  the  next  specified 
el ement . 

BUFFER  LIMIT  ERROR  - Either  the  supplied  user  buf- 
fer has  been  filled  or  121  characters  have  been 
read  in  the  cgetO  routine.  The  routine  will  wait 
for  either  a carriage  return  or  erasure  (cntrl-a) 
of  part  of  the  buffer  contents. 

FORMAT  ERROR  - The  desired  output  string  exceeds 
100  characters  in  the  printvC)  routine.  The 
routine  will  print  only  the  first  100  characters. 

WRITE  ERROR  - The  write  direction  parameter  is  in 
error.  A default  value  of  HOR  will  be  assumed  and 
the  routine  continued. 

SLANT  ERROR  - The  slant  parameter  is  in  error.  A 
default  value  of  NSLNT  will  be  assumed  and  the 
routine  continued. 

SIZE  ERROR  - The  size  parameter  is  in  error.  A 
default  value  of  SZA  will  be  assumed  and  the 
routine  continued. 


109 


APPENDIX  B 


USER  SUPPORT  ROUTINE  DESCRIPTIONS 


The  descrlotion  of  the  user  interface  routines  apoeer  in 
a format  similar  to  the  routine  descriptions  in  the  UNIX 
Reference  Manual  at  the  Naval  Postgraduate  School  Computer 


• PC 


• PC 


IT 

NAME: 

•PC  * dP^M  •n  apc 


! 

I 


i 

! 


SYNOPSIS: 

2~di mensi onal  coopdfnate  system 

VR/VA  : aPC (di p > cent X > cent y » endx »endy ) 

VRX/VAX:  spc (di p#centy»endy ) 

VRY/VAY:  SPC (d i p f cent X » endx ) 

VRZ/VAZ:  not  allowed 

3'di mens i ona I coopdinate  system 

VR/VA  : aPc (dl p>centx»centy fcentz/endx#endy»endz) 
VRX/VAX:  apc(dipfcentyrcentz» endy »endz ) 

VRY/VAY:  apcldip^centx  r cent  z /endx  f endz ) 

VRZ/VAZ:  apc(dip»centx/centy»endx» enoy ) 

int  dip:  CC  / 004  - countep  clockwise 
C / 010  - clockwise 

float  centx»centy»centz» endx » endy r endz ; 


DESCRIPTION: 

An  apc  is  dpswn  from  the  opesent  beam  location^  about 
a centep  ooint  to  an  end  point.  The  location  of  the 
centep  and  end  points  depend  upon  the  specified  vectop 
type  and  supplied  centep  and  end  point  pspameteps. 
The  papameteps  passed  fop  the  centep  and  end  points  of 
the  spc  spe  eithep  pelative  op  absolute  values.  The 
numbep  and  value  of  these  papameters  are  determined  by 
the  vectop  type  selected  in  the  ppevious  call  to  set~ 
vectopO.  If  the  centep  point  is  not  an  eoual  dis* 
tance  fpom  the  stapting  point  of  the  aPC  and  the  end 
point*  an  apc  wilt  be  dpawn  using  one  of  the  distances 
as  the  padius.  The  pesult  is  a stpaight  line  dPawn 
fpom  the  actual  tepminating  ooint  of  the  aPC  to  tne 
end  point. 

If  the  vectoP  type  is  an  absolute  vectoP*  the  centep 
and  end  points  will  be  as  given  in  the  oapametep  list. 
AutO'incpement  vectOP  tyoes  will  cause  the  centep  and 
end  points  to  have  the  same  cooPdinate  value  as  the 
stSPting  point  foP  the  designated  auto-i  nc  pement  coop** 
dinate.  Under  absolute  vectop  types*  pspametePS  which 
fall  outside  the  defined  coopdinate  system  will  assume 
a value  of  the  neopest  coopdinate  within  the  defined 
system. 
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arc 


arc 


If  the  vector  type  fs  a relative  vector^  the  end  point 
of  the  arc  will  be  obtained  by  adding  the  endxr  endy* 
and  endz  values  to  the  starting  point.  The  center 
point  is  then  obtained  by  adding  the  centvr  centy.  and 
centi  values  to  the  previously  obtained  endpoint.  As 
with  absolute  vectors,  auto'i nc recent  modes  cause  the 
center  and  end  points  to  have  the  same  coordinate 
value  as  the  starting  ooint  for  the  designated  auto* 
increment  coordinate.  Under  relative  vector  types* 
parameters  which  exceed  one*ha1 f the  coordinate  range 
will  be  set  to  zero. 

Arcs  cannot  be  drawn  by  any  of  the  four  incremental 
vectors . 


DIAGNOSTICS: 

All  errors  will  be  orinted  on  the  POP-11  terminal 
screen. ' 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return 

E-2 

No  more  space  available 
in  display  list 

Return 

E-3 

The  draw  direction  was  not 
defined  as  C or  CC 

di  r s C 

E-11 

30  not  defined 

Return 

E-15 

The  X value  was  out-of-bounds 

X s xmi n 

or  xmax 
or  0.0 

E-16 

The  y value  was  out-of-bounds 

y = ym i n 
or  ymax 
or  0.0 

E-17 

The  z value  was  out-of-bounds 

z = zmin 
or  zmax 
or  0.0 

E-19 

Illegal  arc  instruction 
from  incremental  vector 

Return 

ALSO  SEE: 

circle*  setvactor 
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blink 


blink 


NAME: 

blink  - blink  the  entire  oicture  or  the  specified 
object  or  elements 


SYNOPSIS; 

bl i nk (ec t i on^num# "ob  j name" » "elel"»"ele2"»...»"elel0"); 

int  action:  ON  / 01  blink 

OFF  / 00  stop  blinking  action 

int  num:  PIC  / 00  oicture 

OBJ  / -I  object 

1 - 10  elements 

To  blink  the  entire  picture: 

bl i nkCact i on^PIC) ; 

✓ 

To  blink  a specific  object: 

bl  ink(actionfOBJ«"obi name" ) * 

To  blink  elements  of  a specific  object: 

bl ink(action»num*"obj  name" » "elel"»"ele2"»...); 


DESCRIPTION: 

The  blink  mode  for  the  entire  picture^  a single  ob- 
ject or  any  number  of  elements  of  a specific  object# 
can  be  turned  on  or  off. 

Modifying  the  blink  mode  of  an  object  affects  all  ele- 
ments linked  to  that  object. 

The  parameter  'num'  specifies  the  number  of  element 
names  being  passed  in  this  routine  and  can  vary 
between  1 and  10. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  POP-II  terminal 


cget 


cg«t 


NAME: 

cg*t  - get  ASCII  characters  from  the  VG  keyboard 
SYNOPSIS: 

cgetlbuffer# 1enath>xoos»ypos): 
char  *buffer; 
int  length; 
float  xpos»ypos: 


r 

i 


r • 
•S 


DESCRIPTION: 

This  routine  allows  for  buffered  input  from  the  VG 
keyboard  to  be  displayed  on  the  display  screen  and 
inserted  in  a user^suppl i ed  buffer.  Parameters  allow 
for  the  positioning  of  the  display  buffer  on  the 
screen  in  absolute  coordinates.  The  length  of  the 
user*suppl i ed  buffer  must  be  specified  in  the  parame- 
ter 'length'. 

A blinking  cursor  indicates  the  beginning  of  the 
buffer  and  the  character  site.  Characters  may  be 
entered  into  the  buffer  and  onto  the  screen  up  to  a 
maximum  of  either  121  characters  or  the  size  of  the 
supplied  user  buffer^  whichever  is  smaller. 

Contents  mav  be  erased  from  the  screen  and  the  user 
buffer  by  repeated  cntrl-a  keystrokes.  A C/R  will 
terminate  the  input  string^  delete  the  display  of  the 
buffer  contentSr  and  insert  a '\0'  as  the  next  charac- 
ter in  the  user  buffer  to  indicate  termination  of  the 
string, 

A listing  of  the  ASCII  character  code  for  every  key- 
board entry  is  listed  o/t  the  following  page. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  POP-11  terminal 
screen . 

ERROR  CAUSE  ACTION 

E-R  Object  limit  exceeded  Return 

E-15  Specified  xpos  out-of-bounds  xpos  > xmin 

or  xmax 
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cget 


cget 


E«16  Specified  ypos  out-of-bounds 

E-20  Either  121  characters  entered 
or  user  buffer  limit  reached 


yPOS  s ymin 
or  ymaK 
Wait  for  CR 
or  CNTRL-A 


ALSO  SEE: 

igetr  fget 


OCTAL 

CHARACTER 

GENERATED 

V6 

KEYBOARD 

CODE 

SYMBOL 

SYMBOL 

000 

NULL 

( i gnored) 

ii  Ctrl 

001 

SO  erase  last  char. 

A Ctrl 

002 

STX 

( ignpred) 

B Ctrl 

003 

ETX 

(ignored) 

C Ctrl 

004 

EOT 

( i gnored) 

0 Ctrl 

005 

ENQ 

( i gnored) 

E Ctrl 

006 

ACK 

( i gnored) 

F Ctrl 

007 

BEL 

C i gnored ) 

G Ctrl 

010 

BS 

BS 

Oil 

HT 

(LF,  cent) 

I Ctrl 

012 

LF 

LF 

013 

VT 

(top,  cent) 

K Ctrl 

014 

FF 

(top,  left) 

L Ctrl 

015 

NL 

(CR,  LF) 

CR 

016 

SE 

( i gnored) 

N Ctrl 

017 

SI 

( i gnored) 

0 Ctrl 

020 

OLE 

(clear  queue) 

P Ctrl 

021 

OCl 

(-LF) 

Q Ctrl 

022 

DC2 

(-SZ) 

R Ctrl 

023 

OC3 

(♦SZ) 

S Ctrl 

024 

DC4 

( termi nate) 

T Ctrl 

025 

NAK 

( i gnored) 

U Ctrl 

026 

SYN 

( i gnored) 

V Ctrl 

027 

ET8 

( i gnored) 

H Ctrl 

030 

CAN 

( ignored) 

X Ctrl 

031 

EM 

( i gnored) 

Y Ctrl 

032 

SUB 

(ignored) 

Z Ctrl 

033 

ESC 

(escape) 

( Ctrl 

034 

FS 

( i gnored) 

\ Ctrl 

035 

GS 

( ignored) 

I Ctrl 

036 

RS 

( i gnored) 

A Ctrl 

037 

US 

( i gnored) 

-.•Ctrl 

040 

space 

sp  bar 

041 

1 

1 shift 

042 

It 

2 shift 
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043 

« 

3 shift 

044 

S 

4 shift 

045 

X 

5 shift 

046 

& 

6 shift 

047 

1 

7 shift 

050 

( 

8 shift 

051 

) 

9 shift 

052 

* 

! shift 

053 

♦ 

; shift 

054 

t 

055 

- 

- 

056 

• 

• 

057 

/ 

/ 

060 

0 

0 

061 

1 

1 

062 

2 

2 

063 

3 

3 

064 

4 

4 

065 

5 

5 

066 

6 

6 

067 

7. 

7 

070 

6 

8 

071 

9 

9 

072 

• 

• 

• 

• 

073 

• 

9 

• 

9 

074 

< 

t shift 

075 

s 

- shift 

076 

> 

. shift 

077 

•> 

• 

/ shift 

100 

9 

a 

101 

A 

A shift 

102 

B 

B shift 

103 

C 

C shift 

104 

D 

0 shift 

105 

E 

E shift 

106 

F 

F shift 

107 

G 

G shift 

110 

H 

H shift 

111 

I 

I shift 

112 

J 

J shift 

113 

K 

K shift 

114 

L 

L shift 

115 

M 

M shift 

116 

N 

N Shift 

117 

0 

0 shift 

120 

P 

P shift 

121 

Q 

Q shift 

122 

R 

R shift 

123 

S 

S shift 

124 

T 

T shift 

125 

U 

U shift 

126 

V 

V shift 

117 


cg*t 


cget 


I 


\ 


j 

i 


127 

M 

W 

shift 

130 

X 

X 

shift 

131 

Y 

Y 

shift 

132 

z 

z 

shift 

133 

I 

t 

134 

\ 

\ 

135 

1 

J 

136 

A 

(suoerscript ) 

A 

137 

(subscript ) 

— 

140 

% 

a 

Shi  ft 

141 

a 

A 

142 

b 

e 

143 

c 

c 

144 

d 

D 

145 

e 

E 

146 

f 

F 

147 

g 

G 

150 

h 

H 

151 

i 

I 

152 

i 

J 

153 

k 

K 

154 

1 

L 

155 

m 

M 

156 

n 

N 

157 

0 

0 

160 

0 

P 

161 

g 

Q 

162 

r 

R 

163 

s 

S 

164 

t 

T 

165 

u 

U 

166 

V 

V 

167 

w 

M 

170 

K 

X 

171 

V 

Y 

172 

z 

Z 

173 

{ 

( 

shift 

174 

• 

1 

\ 

shift 

175 

> 

1 

shift 

176 

A 

shift 

177 

DEL 

240 

O 

space  spec 

241 

1 

shift 

spec 

242 

ff 

2 

shift 

spec 

243 

0 

3 

shift 

spec 

244 

t 

4 

shift 

spec 

245 

y 

(csntsrcd) 

5 

shift 

spec 

246 

/ 

6 

Shift 

soec 

247 

r 

7 

shift 

spec 

250 

c 

8 

shift 

spec 

251 

g 

Shift 

spec 

252 

(subscript ) 

a 

a 

shift 

spec 

cg«t 


cget 


253 

* 

; shift 

spec 

25« 

t spec 

255 

S 

- spec 

256 

ft 

. spec 

257 

/ spec 

260 

• 

0 spec 

261 

1 spec 

262 

2 spec 

263 

□ 

3 spec 

269 

4 spec 

265 

A 

(centered) 

5 spec 

266 

» 

6 spec 

267 

X 

7 spec 

270 

u 

0 spec 

271 

n 

9 spec 

272 

• 

(center  dot) 

: spec 

273 

X 

; spec 

274 

t shift 

spec 

315 

a 

M shift 

spec 

316 

N shift 

spec 

317 

a 

0 shift 

spec 

320 

P shift 

spec 

321 

o 

Q shift 

spec 

322 

> 

R shift 

spec 

323 

S shift 

spec 

324 

T shift 

spec 

325 

1 

U shift 

spec 

326 

f 

V shift 

spec 

327 

A 

W shift 

spec 

330 

t 

X shift 

spec 

331 

f 

Y shift 

spec 

332 

— 

Z shift 

spec 

333 

L 

[ spec 

334 

♦ 

\ spec 

335 

K 

1 spec 

336 

— 

/s  spec 

337 

• 

spec 

340 

(b) (nking) 

3 shift 

spec 

341 

X 

A spec 

342 

# 

B spec 

343 

r 

C spec 

344 

0 spec 

345 

t 

E spec 

346 

F spec 

347 

t 

G spec 

350 

X 

H spec 

351 

L 

I spec 

352 

N 

J spec 

353 

/ 

K spec 

354 

X 

L spec 

355 

A 

M spec 

356 

V 

N spec 
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I 


cq«t 


cget 


357 

0 

spec 

360 

t 

p 

spec 

361 

Q 

spec 

362 

e 

R 

spec 

363 

r 

S 

spec 

364 

r 

T 

spec 

365 

7 

U 

spec 

366 

o 

V 

spec 

367 

J 

w 

spec 

370 

1 

t 

spec 

371 

1 

Y 

spec 

372 

y 

Z 

spec 

373 

r 

( 

spec 

shift 

374 

\ 

\ 

spec 

shift 

375 

1 

spec 

shift 

376 

A 

spec 

shift 

377 

■ 

DEL  soec 

i 
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charel  e 


chare  1 e 


P 

NAME; 

charele  - displays  an  ASCII  character  string 
on  the  Vector  General 

SYNOPSIS: 


charele("elename"»charptr»si2e»wdir,slant»xooSfVPos); 


i nt 

size: 

SZ 

/ 

0000 

use  previous  character  size 

SZl 

/ 

0100 

size 

s 100  col  X 60 

lines 

SZ2 

/ 

0120 

size 

= 81  col  X ai 

lines 

SZ3 

/ 

oiao 

s i xe 

= 60  col  X 30 

lines 

sza 

/ 

0160 

size 

= 32  CO  1 X 16 

lines 

i nt 

wdi  r ; 

HOR 

/ 

0000 

write 

hori zontal  1 y 

VER 

/ 

0200 

write 

vertical  1 y 

i nt 

slant: 

SLNT 

/ 00 

slant 

characters 

NSLNT 

/ 01 

no  slant  characters 

float  xpos 

* ypos; 

xpos 

: VGREL  - to 

output 

characters  relative 

to  the  present  beam  position 
the  parameter  xpos  should  be 
replaced  with  VGREL  and  the 
Parameter  ypos  omitted. 


DESCRIPTION: 

This  routine  displays  the  ASCII  character  string, 
specified  by  charptr,  on  the  vector  general  screen. 
The  characters  can  be  output  by  specifying  the  desired 
coordinate  starting  point  (xpos,ypOs}  or  by  outputting 
the  string  relative  to  the  present  beam  location.  The 
symbols  available  include  formatting  symbols  and  an 
extended  character  set.  These  can  be  incluaeo  in  any 
character  string  by  including  the  proper  identifying 
symbols.  The  character  string  formatting  symbols  are: 

KEYBOARD  FORMAT 
SYMBOL 

backspace*  moves  back  one  character  space 
»A  line  feed*  position  center  screen 

#0  line  feed 

»C  position  at  too  center  of  screen 

•0  position  at  top  left  corner  of  screen 

aE  carriage  control*  line  feed 


1. 


charel  e 


charel  e 


ttf  ignored 

•G  ignored 

special  character 
neg*  line  feed;  moves  up  one  line 
#J  decreases  current  character  size  by  one 

i»K  increases  current  character  size  by  one 

Due  to  the  extended  character  set  available  on  the 
vector  general/  all  special  character  symbols  are  pre~ 
ceded  by  a pound  sign.  In  order  to  have  a pound  sign 
appear  on  the  screen/  two  pound  signs  (0#)  must  appear 
in  the  character  string,  A list  of  the  special  char- 
acters available  are  listed  on  the  next  page  under 
Extended  Character  Set. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP-11  terminal 
sc  reen  . 


ERROR 

CAUSE 

ACTION 

e-1 

Routine  has  been  called 
within  a draweleC)  block 

Return 

E-E 

No  space  available  in 
display  list 

Return 

E-a 

Incorrect  ASCII  character  symbol 
found  in  character  string 

None 

E-7 

Duplicate  element  name 

Return 

' E-8 

Maximum  number  of  elements 
exceeded 

Return 

E-15 

Specified  xpos  out-of-bounds 

xpos  ~ xmin 
or  xmax 

E-16 

Specified  ypos  out-of  bounds 

ypos  s ymin 
or  ymax 

E-35 

Improper  'wdir'  parameter 

write  = HOR 

E-36 

Improper  'slant*  parameter 

slant  = 

NSLNT 

E-37 

Improper  'size*  parameter 

Size  : SZa 

circle 


c < PC  1 e 


NAME: 


circle  - drew  a circle 


SYNOPSIS: 


2*dimensiona1  coordinate  system 


VR/VA 

VRX/VAX 

VRY/VAY 

VRZ/VAZ 


circle(dir»centx»centy); 
ci rcleCdi r»centy) ! 
ci rcleCdi r»centx) ; 
not  all  owed 


3*dimensiona1  coordinate  system 

^R/MPk  : c i rc  I e (di  r» cent  X f cent y > cent  z ) ; 
VRX/VAX:  circ1e(dirrcenty>centz); 

VRY/VAY:  circ1e(dir»centx,centz); 

VRZ/VAZ:  circ1e(dir»centx»centy)» 

int  dir:  C / 010  cTockwise 

CC  / OOO  counter-clockwise 


float  centxrcentyrcentz: 


DESCRIPTION: 

A circle  is  drawn  from  the  oresent  beam  location  about 
a center  point.  The  location  of  the  center  point 
depends  upon  the  specified  vector  type  and  supplied 
center  point  parameter.  The  parameters  passed  for  tne 
center  point  of  the  circle  are  either  relative  or 
absolute  values.  The  number  and  value  of  these  param- 
eters are  determined  by  the  vector  type  selected  in 
the  previous  call  to  setvectorC). 

If  the  vector  type  is  an  absolute  vector  then  the 
center  point  of  the  circle  will  be  as  given  in  the 
parameter  list.  Auto-increment  vector  types  will 
cause  the  center  point  to  have  the  same  coordinate 
value  as  the  starting  point  for  the  designated  auto- 
increment coordinate.  Under  absolute  vector  types# 
parameters  which  fall  outside  the  defined  coordinate 
system  will  assume  a value  of  the  nearest  coordinate 
within  the  defined  system. 

If  the  vector  type  is  a relative  vector  the  center 
point  will  be  obtained  by  adding  the  centx#  centy#  and 
centz  values  to  the  starting  point.  As  with  absolute 
vectors#  auto-i ncrament  modes  cause  the  center  point 
to  have  the  same  coordinate  value  as  the  starting 
point  for  the  designated  auto-increment  coordinate. 
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circle 


circle 


Under  relative  vector  tyoesr  oarameters  which  exceed 
one'half  the  coordinate  range  will  be  set  to  zero. 

Circles  cannot  be  drawn  by  any  of  the  four  incremental 
vectors . 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the 
sc  reen . 

POP-ll  terminal 

ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a drawele()  block 

Return 

E-2 

No  space  available  in 
display  list 

Return 

E-3 

Draw  direction  not  defined 
as  either  C or  CC 

dir  s C 

E-ll 

30  not  defined 

Return 

E-15 

The  X value  was  out ~of 'bounds 

X s xm i n 

or  xmax 
or  0.0 

E-16 

The  y value  was  out -of “bounds 

y s ymin 
or  ymax 
or  0.0 

E-17 

The  z value  was  out-of-bounds 

z = zmi n 
or  zmax 
or  0.0 

E-19 

Illegal  circle  instruction 
from  incremental  vector 

Return 

c I rh  i t 


c 1 rh  < t 


NAME: 


clrhit  • dear  oi  c ture/ob  j ec  t /el  ement  HgHtpen  hit 


SYNOPSIS: 

clrhit(num»"obj  name" » "el ename " ) ? 

int  num:  PIC  / 00  dear  all  element  lightpen  hits 

OBJ  / -1  dear  lightpen  hits  on  all 

elements  of  specified  object 
ELE  / ♦!  clear  ligntpen  hit  on  specified 
element  of  specified  object 

To  dear  all  elements  of  lightpen  hits: 

drhit(PIC); 

To  clear  all  elements  of  object  'tree': 
d rh i t (OBJ  t "tree"  ) ; 

To  clear  element  'branchS'  of  object  'tree': 
clrhit(ELE»"tree"» "branchS" ) ; 


DESCRIPTION: 

This  routine  clears  lightpen  hits  on  a single  element* 
group  of  elements*  or  all  elements.  If  PIC  is  speci- 
fied* all  elements  are  cleared  of  lightpen  hits.  If 
OBJ  is  specified*  all  elements  attached  to  the  speci- 
fied object  are  cleared  of  lightpen  hits.  If  ELE  is 
specified*  only  the  indicated  element  of  the  specified 
object  is  cleared  of  a lightpen  hit.  Invalid  parame- 
ters will  result  in  no  action  being  taken. 


DIAGNOSTICS: 


A1 1 errors  will 

be  printed 

on 

the  POP-ll  terminal 

screen. 

ERROR 

CAUSE 

ACTION 

E-5 

Indicated 
es  i St 

objname  does 

not 

Return 

E-6 

Indicated 
ex  i St 

elename  does 

not 

Return 

£-22 

Element  not  linked  to 
specified  object 

Return 
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coordsvs 


coordtys 


»• 


I 


I 


NAME: 

coordsys  - define  user  coordinate  system 


SYNOPSIS: 

coordsys (di m»mi nx » maxx fffl i ny » maxy  (>minz»maxzl  )} 
int  dim:  2 or  3 

float  minx»maxx*mfny.maxy»minz,maxz; 


DESCRIPTION: 

Defines  a two  or  three  dimensional  cartesian  coordi- 
nate system,  of  any  scale,  for  the  user.  The  oarameter 
'dim*  specifies  the  number  of  dimensions  required.  If 
'dim'  is  2 then  only  the  range  of  x and  y need  to  be 
speci f ied. 

minx  must  be  strictly  less  than  maxx. 
miny  must  be  strictly  less  than  maxy. 
minz  must  be  strictly  less  than  maxz. 

All  subsequent  user  coordinate  values  are  interpreted 
according  to  this  user  defined  coordinate  system. 

If  coordsysC)  is  not  called  bv  the  user  the  default 
values  will  be  taken.  The  default  coordinate  system  is 
three  dimensional  with  x,  y,  z ranging  from  -100.0  to 
100,0.  All  coordinate  values  received  will  be  inter- 
preted according  to  these  default  values  unless  the 
coordinate  system  is  redefined  by  the  user. 


DIAGNOSTICS: 

Any  values  which  fall  outside  of  the  defined  coordi- 
nate system  will  produce  an  error  message  specifying 
which  coordinate  value  was  out-of-bounds.  If  the 
value  was  an  absolute  coordinate,  the  nearest  coordi- 
nate within  the  defined  coordinate  system  will  be 
assumed.  If  the  value  was  a relative  value  that  was 
out-of-bounds,  a value  of  zero  will  be  assumed. 

All  errors  will  be  printed  on  the  PDP-11  terminal 
screen. 
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coordsys 


coordsys 


ERROR 
E-l  1 


CAUSE 

Dimension  not  soecified  as 
20  or  30 


ACTION 

Return 


copyel  t 


coove  I e 


NAME: 

copvele  * specify  additional  names  to  be  used 

in  referencing  a specific  element  block 


SYNOPSIS: 

copyel  e (num»  "e1ename’*»"namel"»"name2"»....»  "name  10"); 
int  num:  1 to  10 


DESCRIPTION: 

This  routine  allows  the  user  to  give  several  unique 
names  to  a specific  element  block.  In  this  manner#  a 
user  can  link  one  element  to  an  object  several  times 
and  can  uniquely  reference  each  occurrence  of  the 
element  within  the  object. 

The  parameter  'num'  specifies  the  number  of  element 
names  being  passed  in  this  routine  and  can  vary 
between  1 and  10. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  POP-11  terminal 

screen. 


ERROR 

CAUSE 

ACTION  i 

E-6 

Spec i f i ed 
exist 

e 1 ename 

does  not 

Return 

E-7 

Oupl icate 

el ement 

name 

Skip  1 

element 

E-a 

Maximum  number  of 
exceeded 

el ements 

Return 

E-18 

Parameter 

'num'  not  1 to  10 

num  =10  ; 

. I 

:1 


cursor 


cursor 


NAME; 


cursor  - act  i vate/deact  i vat:e  display  of  specified 
device  cursor 


SYNOPSIS: 


cursor(dev» action); 


i nt 

dev;  LPEN  / 

00 

1 i ghtpen 

TRK  / 

01 

t rac  kba 1 1 

JOY  / 

02 

joyst i ck 

i nt 

action:  OFF 

/ 00 

turn  cursor 

di sol  ay  off 

ON 

/ 01 

turn  cursor 

display  on 

DESCRIPTION: 

This  routine  will  act i vate/deact i vate  the  oisolay  of 
the  specified  device  cursor  depending  on  the  specified 
'action*  value. 

The  trackball  and  joystick  cursors  are  displayed  as 
clinking  plus  signs.  The  trackball  cursor  is  two 
dimensional  and  may  be  moved  along  the  X-Y  plane.  The 
joystick  cursor  is  drawn  two  dimensionally  but  can 
move  in  all  three  dimensions.  As  the  joystick  cursor 
moves  along  the  Z axis  its  intensity  cueing  is  affect- 
ed. Both  trackball  and  joystick  cursors  may  be  moved 
without  being  displayed. 

The  lightoen  cursor  is  a small  non-blinking  octogon. 
It  is  drawn  in  two  dimensions  and  can  only  move  alono 
the  X-Y  plane.  The  lightpen  mav  onlv  be  moved  while 
being  displayed.  Eighteen  cursor  movement  may  be 
accomplished  in  one  of  two  speeds*  depending  upon 
whether  the  lightpen  sense  switch  is  on. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  PDP-11  terminal 

sc  reen . 

ERROR  CAUSE  ACTION 

E-2U  Improper  'action'  value  Return 

E-27  Improper  'dev'  number  Return 
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a 


dial 


dial 


NAME: 

dial  ~ return  value  of  specified  dial 

SYNOPSIS: 

di al (num) > 
int  num:  I-IO 
doub I e di a I ( ) ; 


DESCRIPTION! 

This  routine  returns  to  the  user  a double  orecision 
value  from  -1.0  to  tl.O  of  the  soecified  dial.  A zero 
(0)  is  returned  to  the  user  if  an  improoer  dial  'num* 
i s spec i f i ed . 

To  obtain  the  double  orecision  value  from  this  routine 
the  function  declaration  "double  diaH)?"  must  be  made 
in  the  users  program. 

DIAGNOSTICS: 

All  errors  will  be  printed  on  the  PDP-11  terminal 

screen . 

ERROR  CAUSE  ACTION 

E-25  Improoer  dial  'num'  Return  0.0 
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di so  I ay 


display 


P 

NAME; 

display  • activate/deactivate  display  of  the  entire 
picture*  an  object*  or  an  element 


SYNOPSIS; 

display! acti on *tyoe*"objname"*"elel"*....*"elelO")* 

int  action;  ON  / 01  turn  display  on 

OFF  / 00  turn  display  off 

int  type;  PIC  / 00  entire  picture 

OBJ  / -1  specified  object 
1 - 10  individual  elements 

To  activate  display  of  entire  picture; 

di sol  ay (ON  * PIC  ) ; 

To  deactivate  display  of  an  object; 

disoIay(OFF,O0J*"obj  name" ) * 

To  deactivate  display  of  3 elements  in  an  object; 
disolay(0FF,3*"objn8me"*"elel"*"ele2"*"ele3"); 


DESCRIPTION; 

This  routine  will  activate  or  deactivate  the  display 
of  the  entire  picture*  an  object*  or  elements  within 
an  object  depending  upon  the  'action'  oarameter. 
Unlike  the  erase!)  and  remove!)  routines*  this  routine 
does  not  affect  the  el ement -ob j ec t relationships*  but 
simply  turns  the  display  of  its  parameters  either  on 
or  off.  The  routine  should  not  be  confused  with  the 
vgpicture!)  routine  which  must  be  called  to  initiate 
the  display  of  elements. 


DIAGNOSTICS; 

All  errors  will  be  printed  on  the  PDP-11  terminal 

sc  reen . 

ERROR  CAUSE 

E-5  Specified  objname  not  found 
E-6  Specified  element  not  found 
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display 


display 


E-10  Parameter  'tyoe'  not  -1  to  10 
E«22  Element  not  linked  to 
specified  object 


ALSO  SEE: 

vgpicturer  erase#  remove 


type  = 10 
Skip 

e 1 ement 
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drawel e 


drawel e 


► 

I 
I 

r 

I NAME: 

drawele  * start  a draw  element  block 


SYNOPSIS: 

drawele("elename"); 


DESCRIPTION: 

This  routine  specifies  the  beqinninq  of  a draw  element 
blocK.  It  associates  a unique  name  with  the  qroup  of 
draw  instructions  that  fall  in  between  this  call  and  a 
call  to  endelel).  The  resultinq  picture  segment  will 
then  be  referenced  ov  the  name  specified  as  the  ele* 
ment  name  in  this  routine. 

A user  may  want  to  repeat  a specific  element  block 
structure  several  times  within  one  object.  Instead  of 
specifying  several  element  blocks  which  describe  the 
same  structure  a user  can  indicate  a group  of  names 
which  refer  to  one  specific  element  block.  These 
unique  names  each  referrinq  to  the  same  structure  can 
then  be  linked  to  an  objects  and  each  can  be  uniquely 
referenced.  This  association  of  several  names  with  oi^e 
element  can  be  accomplished  by  the  routine  cooyeleC). 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  PDP*1 1 terminal 
screen. 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
within  a drawelel)  block 

Return 

E-2 

No  space  available 
in  display  list 

Return 

E-7 

Dupl icate  el ement 

name 

Return 

E-a 

Maximum  number  of 
exceeded 

e 1 ement  s 

Return 

ALSO  SEE: 

copyelcf  object 
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► 

! 


» 


I 

p- 

ft 

f 

y 


•ndele  endele 

NAME: 

•ndele  - end  of  the  current  element  block 


SYNOPSIS; 

ende 1 e ( ) f 


DESCRIPTION: 

Specifies  the  termination  of  a list  of  draw  instruc* 
tions  describing  a specific  element.  The  picture  seg- 
ment described  by  a group  of  draw  instructions  that 
fall  between  a drawe1e()  and  endeleC)  call  will  be 
referenced  by  the  name  specified  in  the  drawele() 
call. 

A new  element  block  cannot  begin  until  the  previous 
block  has  been  properly  terminated  by  a call  to  en* 
del e( ) . 


DIAGNOSTICS: 

This  routine  must  be  called  to  properly  end  a draw 
element  block.  If  a block  is  not  properly  terminated 
prior  to  the  beginning  of  a new  element  block*  all 
draweleO  calls  will  be  ignored  and  any  draw  instruc- 
tions that  follow  will  be  associated  with  the  element 
block  that  has  not  been  terminated. 

All  errors  will  be  printed  on  the  PDP-tl  terminal 


sc  reen . 

ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return 

i 


13S 


• rate 


erase 


NAME: 


erase  * erase  the  soecified  oortions  of  the  picture 


SyNOPSIS; 

erase  (nuiB»  "ob  j name" » "elel"/"e1e2"»..../"e1el0"); 

int  num:  PIC  / 00  all  elements 

OBJ  / *1  all  elements  within  specified 
object 

1 - 10  soecified  elements  within 
soec i f i ed  object 

To  erase  the  entire  picture: 

erase(PIC) ! 

To  erase  a specific  object: 

erase(OBJ»"obj  name" ) ; 

To  erase  elements  of  a specific  object: 
erase (num » "ob  j name" f"elel"»"ele2 


DESCRIPTION: 

The  entire  picture^  soecified  object  or  the  listed 
elements  of  a specific  objects  will  be  erased  from  the 
vector  general  display  screen.  The  elements  still 
exist.  To  redisplay  any  portion  of  the  erased  picture/ 
the  appropriate  el ement-ob j ect  linking  must  again  oe 
done  by  the  user. 

The  parameter  'num*  specifies  the  numper  of  element 
names  being  passed  in  this  routine  and  may  vary 
between  1 and  10. 


DIAGNOSTICS: 


A1 1 errors  will  be 

printed  on 

the 

PDP-l 1 termi nal 

screen. 

ERROR 

CAUSE 

ACTION 

E-5 

Spec i f i ed 
ex  i St 

ob  j name 

does 

not 

Return 

E-6 

Soec i f i ed 
ex  i St 

el ement 

does 

not 

Skip 

el ement 

I 


erase 


E-18  Parameter  'num'  not  -1  to  10 
E*22  Element  not  linked  to 
specified  object 


num  s 10 
Skip 

element 


ALSO  SEE: 

remove^  display^  object 


5 

i 


t 


' i 

1 


lao 


crrormsg 


•rrormsg 


NAME: 


errormsq  - print  error  messages  on  PDP-11  terminal 
screen 

SYNOPSIS: 

errormsg(sction); 

int  action:  ON  / 01  print  error  messages 

OFF  / 00  do  not  print  error  messages 


DESCRIPTION: 

All  error  messages  will  automatically  be  printed  on 
the  POP-11  terminal  screen.  The  user  can  control  the 
printing  of  error  messages  during  any  portion  of  a 
program  by  calling  this  routine. 


fget  • g«t  • floating  point  number  from  the  VG 
keyboard 


SYNOPSIS: 

fget ( (num* iooa»  vDosI ) ; 

int  nu«:  ABS  / 01  absolute  coordinate  indicator 

float  KDoSfypos:  («>y)  absolute  coordinate 

To  return  a floating  point  number  and  begin  input 
display  buffer  at  (50.0»75.0)  absolute: 

fget(ABS»50. 0,75.0); 

To  return  a floating  point  number  and  begin  input 
display  buffer  at  («min,ymin)  absolute: 

fget ( ) ; 


DESCRIPTION: 

This  routine  returns  to  the  user  a floating  ooint 
number  from  the  VG  keyboard.  The  routine  is  similar 
to  getfC)  and  in  fact  uses  getf()  to  accomplish  its 

task . 

The  optional  parameters  allow  the  user  to  position  the 
input  display  buffer  anywhere  on  the  display  screen. 
The  'apes'  and  'yoos'  parameters  are  absolute  floating 
ooint  coordinates.  If  no  parameters  are  given  the 
input  buffer  will  begin  at  (amin,ymin).  Coordinate 
parameters  which  fall  outside  the  defined  coordinate 
system  will  assume  a value  of  the  nearest  coordinate 
within  the  defined  system. 

The  input  display  buffer  is  drawn  with  the  help  of  a 
call  to  the  cgetO  routine.  The  input  display  buffer 
has  a maiimum  size  of  20  characters  before  an  error 
message  is  displayed. 

To  obtain  the  floating  point  value  from  this  routine 
the  function  declaration  "float  fget();”  must  be  made 
in  the  users  orogram. 


fget 


^g«t 


DIAGNOSTICS: 


AJl  erropf  will  be  printed  of  th®  P0P*1 1 termin*) 
screen. 


ERROR 

E-15 

CAUSE 

Soec i f i ed 

XDOS 

out-of-bounds 

ACTION 
xpos  s xnin 

E«16 

Soec i f i ed 

yoos 

out-of-bounds 

or  xmax 
VPOS  * ymin 

E-33 

Buffer  limit  of 

20  characters 

or  ymax 
#<ait  for  CR 

ALSO  SEE: 

iget  f 

reached 

• 

cget 

or  CNTRL-A 

I 


f snan 


f sman 


NAME: 

fsman  • check  function  switch  depressed 

SYNOPSIS: 

f smanCnum)  i 
int  nu*:  0-51 


DESCRIPTION: 

This  routine  checks  the  status  of  the  specified  func- 
tion Switch  and  returns  a one  (1)  if  depressed  and  a 
zero  (0)  if  not  depressed.  Unlike  fstogO#  lamps  are 
not  lighted  by  this  routine  and  a one  is  returned  only 
so  long  as  the  switch  is  physically  depressed. 

It  is  not  recommended  that  both  fstogC)  and  fsmanO  be 
used  in  the  same  program.  Due  to  the  operation  of  the 
routine  fstog()«  if  both  routines  are  used  the  lamp 
status  on  switches  queried  by  fsman()  should  be  disre- 
garded. 

A zero  is  returned  if  an  improper  function  switch 
•num'  is  specified. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  PDP-11  terminal 

screen. 

ERROR  CAUSE  ACTION 

E-23  Improper  function  Switch  Return  0 

•num*  soeci tied 


ALSO  SEE: 


laa 


fstog#  lamp 


f Stoq 


f stog 


NAME: 


fstog  - check  function  switch  toggle 


SYNOPSIS: 

f stogfnum) ; 
int  num:  0 • 31 


DESCRIPTION: 

This  routine  checks  the  specified  funct^ion  switch  and 
returns  a one  (I)  and  lights  the  aooropriate  lamp  on 
the  odd  ( 1 St / 3rdr 5t h / . . . . ) depressions  of  the  function 
switch.  The  return  value  and  lamp  status  remain  the 
same  until  the  next  even  (2nd»<lthf  6thf  . . . . } depression 
of  the  function  switch  whereupon  a zero  (0)  is  re- 
turned and  the  lamp  extinguished. 

It  is  not  recommended  to  use  both  fstog()  and  fsman() 
routines  in  the  same  program;  however^  if  both  are 
used/  disregard  the  lamp  status  of  function  switches 
queried  by  fsmanO. 

A zero  is  returned  if  an  improper  function  switch 
* num ' i s spec i f i ed. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  POP-li  terminal 

screen. 

ERROR  CAUSE  ACTION 

E-23  Improper  function  switch  Return  0 

'num*  specified 


ALSO  SEE: 

fsman/  lamp 


IMS 


igct 


1 qet 


NAME; 

iget  - get  an  integer  from  the  VG  keyboard 
SYNOPSIS; 

i get  ( [nutn»  xoos#  voos)  ) I 

int  num;  ABS  / 01  absolute  coordinate  indicator 

float  xposrypos;  (x>y)  absolute  coordinate 

To  return  an  integer  and  begin  input  display  buffer  at 
(•25*0fl7.0)  absolute; 

iget (ABS, -25.0, 1 7.0) ; 

To  return  an  integer  and  begin  input  display  buffer  at 
(xniin,ymin)  absolute; 

iget ( ) ; 


DESCRIPTION; 

This  routine  returns  to  the  user  an  integer  fro"*  the 
VG  keyboard.  The  routine  is  similar  to  geti()  and  in 
fact  uses  getiO  to  accomplish  its  task. 

The  optional  parameters  alloM  the  user  to  position  the 
input  display  buffer  anywhere  on  the  display  screen. 
The  'xpos*  and  'ypos*  parameters  are  absolute  floating 
point  coordinates.  If  no  parameters  are  given  the 
input  display  buffer  will  begin  at  (xmin,ymin).  Coor- 
dinate Parameters  which  fall  outside  the  defined  coor- 
dinate system  will  assume  a value  of  the  nearest  coor- 
dinate within  the  defined  system. 

The  input  display  buffer  is  drawn  with  the  help  of  a 
call  to  the  cget()  routine.  The  input  display  buffer 
has  a maximum  size  of  20  characters  before  an  error 
message  is  displayed. 


1 


DIAGNOSTICS; 


All  errors  will  be  printed  on  the  PDP-11  terminal 

screen. 

ERROR  CAUSE  ACTION 

E-15  Soecified  xpos  out  of  bounds  xpos  ~ xmin 

or  xmax 

lao 


c~16  Soecified  vdos  out  of  bounds 

E“33  Buffer  limit  of  20  characters 
reached 


VPOS  = ymin 
or  ymax 
Wait  for  CR 
or  CNTRL-A 


ALSO  SEE: 


fget»  cget 


intoff  set 


i ntof  f set 


NAME: 


intoffset  - object  intensity  offset 


SYNOPSIS: 

intoffset("objname"»va1  ) i 
float  val:  0.0  to  1.0 


DESCRIPTION; 

The  intensity  ranoe  of  the  specified  object  is  deter- 
mined by  the  parameter  'val*.  If  'val*  is  one»  the 
maximum  intensity  range  is  achieved.  If  the  value  is 
zero#  the  intensity  is  constant  and  the  image  has  no 
depth-cuei ng. 


DIAGNOSTICS: 


A1 1 errors  will  be 

printed  on  the 

POP-1 1 terminal 

screen. 

ERROR 

CAUSE 

ACTION 

E-5 

Spec i f i ed 

object  does  not 

Return 

E-30 

exist 

Parameter 

' val ' not  0.0  to  1 

.0  Return 

ALSO  SEE: 


i nt  sea  1 e 


intscale 


I. 


t nt  sea ) e 


NAME: 

/ 

intscale  - modify  object  intensity  scale 


SYNOPSIS; 

intsca1e("objnatne''»val  >cut); 
f loat  val : 0.0  to  1.0 

intcut;  Oorl 


DESCRIPTION; 

The  intensity  ranoe  of  an  object*  which  gives  a 
three-dimensional  object  its  depth  cueing,  is  deter- 
mined by  the  parameter  'val'.  The  range  of  'val'  is 
from  zero  to  one.  If  'val'  is  one  the  maximum  intensi- 
ty range  is  obtained;  if  it  is  zero  the  object  has  no 
depth  cueing. 

The  parameter  'cut'  provides  for  the  use  of  a screen 
cut-off  plane.  If  the  value  of  'cut*  is  one  then  the 
cut-off  plane  provisions  are  in  effect.  If  the  value 
is  zero  there  will  be  no  screen  cut-off  plane. 


DIAGNOSTICS; 


A 1 1 errors  will  be 

pr i nted 

on 

the 

sc  reen . 

ERROR 

CAUSE 

E-S 

Spec i f i ed 

objname  does  not 

exist 

E-30 

Parameter 

'val'  not 

0.0 

to  1 

E-51 

Parameter 

'cut'  not 

0 or 

1 

POP- 1 t terminal 


ACTION 

Return 

.0  Return 

Return 


! 

I 


i 

i 


ALSO  SEE; 

i ntof  f set 


la9 


t ano 


1 amp 


NAME  : 

lamp  - 1 i gh t /ext i ngui sh  specified  lamp 
SYNOPSIS: 


1 amp ( num r act  ion)  7 

i nt 

num : 0 

- 31 

i nt 

action: 

OFF  / 

00 

turn 

1 amp 

off 

ON  / 

01 

turn 

1 amp 

on 

DESCRIPTION: 

This  routine  lights/extinguishes  the  specified  lamp 
depending  on  the  soecified  'action'  parameter.  An 
'action'  value  of  OFF  Mill  extinguish  the  specified 
lamp»  Mhile  a value  of  ON  Mill  light  the  appropriate 
lamp.  An  imoroper  lamp  'num'  or  'action'  will  result 
in  no  action  being  taken. 


DIAGNOSTICS: 

All  errors  Mill  be  printed  on  the  PDP-11  terminal 
sc  reen . 

ERROR  CAUSE  ACTION 

E-23  Improper  lamp  'num'  specified  Return 

E-2U  Improper  'action'  value  soecified  Return 

ALSO  SEE: 

f stog 
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1 ghtpen 


1 ghtoen 


NAME: 


Ightpen  - set  lightPen  sensitivity  of 

the  pi c t ure» ob j ec t op  elements 


SYNOPSIS: 

1 ghtpen ( ac t i on«  num> "ob  j name" f"e1el"»"ele2"»..,,»"elel0"); 

int  action:  ON  / 01  set  liqhtpen  sensitivity 

OFF  / 00  clear  lightpen  sensitivity 

int  num:  PIC  / 00  picture 

OBJ  / -1  object 

1 - 10  elements 

To  set  sensitivity  of  the  entire  picture: 

1 ghtpen (action>PIC); 

To  set  sensitivity  of  an  object: 

1 ghtpen (action>OBJ>"objname"); 

To  set  sensitivity  of  elements  of  a specific  object: 

1 ghtpen  f ac t i on^num# "ob  j name" / "elel"/"ele2"»...); 


description: 

The  user  can  specify  which  oicture  segments  will  be 
lightpen  sensitive.  These  elements  designated  as 
lightpen  sensitive  will  be  affected  by  liqhtpen  in- 
teraction with  the  vector  general  display  screen. 

The  parameter  'num*  specifies  the  number  of  element 
names  being  passed  in  this  routine  and  may  vary  from  1 
to  10. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  POP-11  terminal 


screen. 

ERROR 

CAUSE 

ACTION 

E-5 

Spec i f i ed 
exist 

ob  j name 

does  not 

Return 

6-6 

Spec i f i ed 
exist 

el ement 

does  not 

Ski  p 
el ement 
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Ightpen 


1 ghtpen 


E-18  Psrawster  'num'  not  •!  to  10  num  * 10 

E*22  Element  not  linked  to  Skip 


specified  object  element 


I 


f 


I < ne 


1 i ne 


NAME: 


line  “ draw  a line 


SYNOPSIS: 


2»di mens i ona 1 coordinate  system 


VR/VA 

VRX/VAX 

VRY/VAY 

VRZ/VAZ 


1 i ne (oarx  fpary ) ; 
1 i ne (oary ) ? 

1 i ne(oarx ) ! 
not  all  owed 


S^dimensional  coordinate  system 


VR/VA 

VRX/VAX 

VRY/VAY 

VRZ/VAZ 


1 ine(Darx»pary»Darz); 
1 i ne (pary  > par z ) ; 

I i ne (parx  # par z ) ; 

1 ine(parx/pary) ; 


float  parxf oary>oarz; 


DESCRIPTION: 


A line  is  drawn  from  the  present  beam  location  to  a 
position  (x»y>z).  The  location  of  (x^y^z)  depends 
upon  the  vector  type  and  the  specified  parameters.. 

If  the  vector  type  is  absolutef  the  location  of 
(x»yfZ)  will  be  (parx foary fOarz ) . If  an  auto* 
increment  mode  is  in  effect*  the  designated  auto- 
increment coordinate  is  left  out  of  the  parameter  list 
and  is  incremented  by  the  designated  increment  to  find 
the  termination  point  of  the  line.  Under  absolute 
vector  types*  parameters  which  fall  outsioe  the  de- 
fined coordinate  system  will  assume  a value  of  the 
nearest  coordinate  within  the  defined  system. 

If  the  vector  type  it  relative*  the  location  of 


(x*y*z)  will  be  the  present 
specified  parameter  values, 
auto-increment  modes  do  not 
auto-increment  coordine*^ 
Under  relative  vector  types* 
one-half  the  coordinate  rt-nge 


beam  location  plus  the 
As  with  absolute  vectors* 
specify  the  designated 
in  the  parameter  list, 
parameters  which  exceed 
will  be  set  to  zero. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  POP-ll  terminal 
screen. 


153 


I i n« 


I { no 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a drawe1e()  block 

Return 

nt 

1 

UJ 

No  space  available  in 
display  list 

Return 

E-15 

Parameter  par*  out-ot-bounda 

par*  = 
or 

or 

*mi  n 
xma* 
0.0 

E-16 

Parameter  pary  out-of-bounds 

pary  s 

or 

or 

ym  i n 
yma* 

0.0 

E-17 

Parameter  oarr  out-of-bounds 

parz  s 

or 

or 

zm  i r 
zma* 
0.0 

ALSO  SEE: 

set  vector 
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► 

manlnt  manint 

r 

manint  • Clear  or  return  manual  interrupt  count 


SYNOPSIS: 

man i nt ( ac  t i on ) ; 

int  action:  CLEAR  / 00  set  count  to  zero 

COUNT  / 01  return  count 


DESCRIPTION: 

This  routine  either  returns  the  present  value  of  the 
manual  interrupt  count  or  resets  the  count  to  zero. 
Each  time  the  manual  interrupt  function  switch  is 
depressed  the  manual  interrupt  count  is  incremented  by 

one . 

An  'action*  value  of  COUNT  will  return  to  the  user  the 
present  manual  interrupt  counts  while  a value  of  CLEAR 
will  reset  the  count  to  zero.  An  improper  'action' 
value  will  result  in  returning  a value  of  zero  but  not 
affecting  the  manual  interrupt  count. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP-11  terminal 
sc  reen . 


ERROR 

CAUSE 

ACTION 

E-2a 

Improper  'action'  value 

Return  0 

* 

mov* 


move 


NAME: 


move  ' move  to  the  soecified  location 


SYNOPSIS: 


^'dimensional  coordinate  system 


VR/VA 

VRX/VAX 

VRY/VAY 

VRZ/VAZ 


moveCoarx/oary) ; 
move (oary ) ; 
move (oarx ) I 
not  ail  owed 


3'di mens i ona i coordinate  system 
VR/VA  : move (oar X f oary « oarz ) ; 
VRX/VAX:  move(oary»oarz) ; 

VRY/VAY:  move(oarxroarz) ; 

VRZ/VAZ:  move (oar X « oary ) ; 


float  oarx roary foarz; 


DESCRIPTION: 

The  beam  is  moved  from  the  oresent  oosition  to  a oosi' 
tion  (x#y»z).  The  location  of  (xrvrz)  deoends  uoon 
the  vector  tyoe  and  the  soecified  oarameters. 

If  the  vector  tyoe  is  absolute*  the  location  of 
(x*y*z}  will  be  (oarx*oary*oarz) . If  an  auto* 
increment  mode  is  in  effect*  the  designated  auto- 
increment  coordinate  is  left  out  of  the  oarameter  list 
and  is  incremented  by  the  designated  increment  to  find 
the  termination  ooint.  Under  absolute  vector  tvoes* 
oarameters  which  fall  outside  the  defined  coordinate 
system  will  assume  a value  of  the  nearest  coordinate 
within  the  defined  system. 

If  the  vector  tyoe  is  relative*  the  location  of 
(x*y*z)  will  be  the  oresent  beam  location  olus  the 
specified  parameter  values.  As  with  absolute  vectors* 
auto'i nc rement  modes  do  not  specify  the  designated 
auto'i ncrement  coordinate  in  the  oarameter  list. 
Under  relative  vector  types*  parameters  which  exceed 
one'half  the  coordinate  range  will  be  set  to  zero. 


DIAGNOSTICS: 


All  errors  will  be  orinted  on 


the  PDP-11 


terminal 
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move 


move 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return 

E-2 

No  space  available  in 
display  list 

Return 

E-15 

Parameter  par«  out-of-bounds 

oar*  = 
or 

or 

xm  i n 

xma* 

0.0 

E-16 

Parameter  pary  out-of-bounds 

pary  * 
or 

or 

ymi  n 
ymax 
0.0 

E-17 

Parameter  parz  out-of-bounds 

oarz  = 
or 

or 

zmi  n 
zmax 

0.0 

ALSO  SEE: 

setvector 


object 


object 


NAME: 


object  - Hntc  elements  to  specified  object  name 


SYNOPSIS: 

object(num»"objname"»"e1el"»"e1e2"f....»"e)el0'’); 
int  num:  I - 10 


DESCRIPTION: 

Associates  with  the  named  object  each  of  the  listed 
elements.  This  picture  segment*  or  element  grouping 
will  be  referenced  bv  the  object  name  specified  in 
this  routine. 

Every  element  must  be  linked  to  at  least  one  object  in 
order  for  it  to  be  displayed  on  the  Vector  General 
screen.  A user  can  link  one  or  more  element  names  to 
an  object.  Elements  can  be  linked  to  an  object  by  one 
or  several  calls  to  this  routine.  An  element  can  be 
linked  to  several  different  objects*  or  one  element 
may  be  linked  several  times  to  the  same  object. 

If  an  object  or  element  has  been  erased  from  the 
display  screen*  a user  can  redisplay  the  desired  ob- 
ject or  elements  by  again  establishing  the  desired 
object-element  association. 

The  parameter  'num'  specifies  the  number  of  element 
names  being  passed  in  this  routine  and  may  vary  from  1 
to  10. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the 

screen. 

PDP-1 1 terminal 

ERROR 

CAUSE 

ACTION 

E-6 

Specified  element  does  not 
eai  St 

Skip 

el ement 

E-e 

Maximum  number  of  elements 
exceeded 

Return 

E-9 

Maximum  number  of  objects 

exceeded 

Return 

E-12 

Add  element  error 

Return 

E-18 

Parameter  'num'  not  1 to  10 

num  s 10 

E-21 

Add  object  error 

Return 
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object  object 

E-32  Element  already  linked  Skip 

e 1 ement 

ALSO  SEE: 


drawele^  cooyele>  eraser  remove 


offset 


offset 


NAME: 


offset  - offset  picture  coordinate  axis 


SYNOPSIS: 

offset (xof f »vof f ) ; 

float  xoffrvoff:  “1.0  to  ♦l.O 


DESCRIPTION: 

This  routine  will  alter  the  positioning  of  the  entire 
picture  on  the  display  screen.  Normal  or  default  pic“ 
ture  positioning  is  centered  on  the  display  screen  and 
corresponds  to  o f f set ( 0 . 0 » 0 . 0 ) . Both  the  X and  Y axes 
may  be  altered  with  this  routine.  Parameters  outside 
the  range  “1.0  to  tl.O  will  result  in  no  altering  of 
the  specified  coordinate  axis. 


DIAGNOSTICS: 


A1 1 errors  will 

be 

or i nted 

on  the  PDP“11  terminal 

screen. 

ERROR 

CAUSE 

ACTION 

E-15 

Speci f ied 

xof  f 

value 

Skip  X axis 

out“of “bounds 

altering 

E-16 

Spec i f i ed 

yof  f 

val  ue 

Skip  Y axis 

out“of“bounds 

al ter i ng 

ALSO  SEE: 

t rans 
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penhi t 


penh  f t 


NAME; 


penhit  • determine  if  ob j ect /el ement  lightpen  hit 


SYNOPSIS: 


penh i t (num » "ob  j name" » "el ename" ) » 


int  num:  OBJ  / •! 

ELE  / tl 


check  penhit  on  abject 
check  penhit  on  element 


To  check  for  lightpen  hit  on  object  'tree*: 
penhit(08J»"tree"); 

To  check  for  lightpen  hit  on  element  'branchS'  of 
object  'tree': 

penh it(ELE/"tree"» "branchS" ) ; 


DESCRIPTION: 


This  routine  checks  to  see  if  an  object  or  element 
within  an  object  has  had  a lightpen  hit.  The  routine 
returns  to  the  user  a one  (1)  if  there  has  been  a 
lightpen  hit  on  the  element  or  objects  otherwise  a 
zero  (0)  is  returned.  When  testing  for  a lightpen  hit 
on  an  object  only  the  first  two  parameters  are  neces- 
sary* and  a one  is  returned  if  any  element  within  the 
object  has  had  a lightpen  hit. 

The  clrhitO  routine  must  be  called  to  clear  an  object 
or  element  of  lightpen  hits.  Invalid  parameters  will 
result  in  a zero  being  returned  to  the  usiir. 

For  an  element  to  register  a lightpen  hit  the 
element's  lightpen  sensitivity  must  be  activated  with 
the  lghtpen()  routine  and  the  lightpen*  with  the  sense 
switch  selected*  must  be  held  over  the  element. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  POP-ll  terminal 

screen. 


ERROR  CAUSE 

E-S  Indicated  objname  does  not 

OK  i St 

E-6  Indicated  elename  does  not 

exist 


ACTION 
Return  0 

Return  0 


I 


penhi  t 


penhi  t 


E«22  Elefnent  not  linked  to 
specified  object 


Return  0 


ALSO  SEE: 


tghtpenr  clrhit 


pi  ace 


pi  ace 


NAME: 

place  - position  object 


SYNOPSIS: 

p 1 ace ( "ob j name" » Kabsy yabs  (^zabsl  ): 
float  xabSf yabsr zabs: 


DESCRIPTION: 

The  specifieC  object#  with  all  its  elements#  is  posi- 
tioned at  abso 1 ut e . 1 ocat i on  ( xabs # y abs # zabs ) . 

The  z parameter  is  required  only  when  the  coordinate 
system  is  defined  as  three  dimensional#  and  will  be 
ignored  if  included  under  a two-dimensional  system. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  POP-11  terminal 

sc  reen . 


ERROR 

E-5 

CAUSE 

Spec i f i ed 

object  does  not 

ACTION 

Return 

E-15 

exist 

Spec i f i ed 

xabs 

out-of-bounds 

xabs  = xmin 

E-16 

Spec i f i ed 

yabs 

out -of-bounds 

or  xmax 
yabs  = ymin 

E-17 

Spec i f i ed 

zabs 

out-of-bounds 

or  ymax 
zabs  = zmin 

or  zmax 

ALSO  SEE: 

offset#  trans 
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posi  t 


DOS  i t 


NAME: 


posit  - return  coordinate  value  of  specified  device 
cursor 


SYNOPSIS: 


Posit(dev»coord): 


i nt 

dev:  LPEN  / 00 

1 i ghtpen  cursor 

TRK  / 01 

t rackba 1 1 cursor 

JOY  / 02 

joystick  cursor 

i nt 

coord:  X / 00 

* coordinate 

Y / 01 

y coordinate 

Z / 02 

z coordinate 

float  DOS i t ( ) : 


DESCRIPTION: 

This  routine  returns  to  the  user  a floating  point 
value  of  the  specified  coordinate  and  device.  The 
value  returned  is  a value  within  the  user  specified 
coordinate  system. 

This  routine  will  return  the  present  position  of  the 
device  cursor  even  though  the  cursor  may  not  be 
currently  displayed.  A coordinate  value  of  zero  is 
returned  if  an  improper  parameter  is  received. 

To  obtain  the  floating  point  value  from  this  routine 
the  function  declaration  "float  positC);"  must  be  made 
in  the  users  program. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP-11  terminal 

sc  reen . 


ERROR 

CAUSE 

ACTION 

E-27 

Improper  'dev*  number 

Return 

0.0 

E-28 

Improper  'coord'  number 

Return 

0.0 

E-29 

No  30  with  LPEN  or  TRK 

Return 

0.0 

ALSO  SEE: 


Cursor 


pr i nt  V 


pr  i nt  V 


r 

I NAME: 

ppintv  - formatted  printf  routine  for  VG  display 


I 


L 


SYNOPSIS: 

printv("e1ename"»size»xrite»slant»xpos/vpos»"format" 
(» arql , arg2* . . . . > arql 01  )i 

int  size:  SZ  / 00  use  previous  character  size 

SZl  / 0100  size  s 100  coJ  x 60  lines 

SZ2  / 0120  size  s 61  col  x ui  lines 

SZ3  / 0140  size  = 60  col  x 30  lines 

SZ4  / 0160  size  s 32  col  x 16  lines 

int  write:  HOP  / 00  horizontal  printing 
VER  / 0200  vertical  printing 

int  slant:  SLNT  / 00  slanted  printing 

NSLNT  / 01  no  slanted  printing 

float  xposrvpos:  absolute  coordinates 

A sample  printed  at  ( *25 . 0« • 1 0 . 0 ) absolute: 

printv("test"»SZ4,HOR»SLNT»-25.0»-10,0# 

"bravoCSl  = Xd” >bravo (51 ) ; 


DESCRIPTION: 

This  routine  is  a formatted  print  routine  similar  to 
the  printff)  routine  except  output  is  to  the  VG 
display  screen.  The  routine  is  a combination  of  the 
chareleO  and  printfO  routines.  The  routine  uses  the 
first  6 parameters  as  the  charele()  routine  does  in 
positioning  and  initializing  an  element  structure. 
Coordinate  parameters  which  fall  outside  the  defined 
coordinate  system  will  assume  a value  of  the  nearest 
coordinate  within  the  defined  system. 

Unlike  ChareleO  the  routine  allows  multiple  calls 
upon  the  same  element#  each  call  updating  the 
element's  character  string.  The  routine  allows  for 
formatted  output  strings  of  up  to  100  characters  be- 
fore an  error  message  is  displayed. 

Each  new  element  declared  in  a printv()  routine  uses 
up  S7  words  of  the  available  display  list  so  care  must 
be  taken  not  to  declare  too  many  new  elements  in  this 
routine.  It  should  be  remembered  that  an  element  may 
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ori nt  V 


pri ntv 


be  used  repeatedly  with  this  routine. 

Elements  originally  declared  elsewhere  as  either  vec* 
tor  drawing  elements  or  character  drawing  elements 
should  not  be  used  in  this  routine.  In  other  words/ 
element  names  found  in  this  routine  should  be  unique 
and  should  not  be  found  in  other  drawele()  or 
charele()  routines. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP-11  terminal 
sc  reen . 


ERROR 

CAUSE 

ACTION 

E-2 

No  more  space  available  in 
display  list 

Return 

E-8 

Maximum  number  of  elements 
exceeded 

Return 

E-15 

Parameter  xpos  out-of-bounds 

X ~ X m i n 

or  xmax 

E-16 

Parameter  ypos  out-of-bounds 

y s ym i n 
or  ymax 

E-3a 

Formatted  output  length 
exceeds  100  characters 

Chop  to  1st 
100  char 

E-35 

Improper  'write'  parameter 

write  = HOR 

E-36 

Improper  'slant'  parameter 

slant  s 

NSLNT 

E-37 

Improper  'size'  parameter 

size  s SZ^i 

ALSO  SEE: 


charel  e 


oscal  • 


pscal e 


NAME: 


oacale  * scale  the  picture 


SYNOPSIS: 

pscal e(val ) ! 

float  val:  0.0  to  1.0 


DESCRIPTION: 

This  routine  will  scale  the  entire  picture.  Normal  or 
default  picture  scaling  corresponds  to  pscale(l.O). 
An  improper  oscaleO  parameter  will  result  in  the  pic- 
ture scale  remaining  the  same  as  before  calling  this 
rout i ne . 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  POP-ll  terminal 
sc  reen . 

ERROR  CAUSE  ACTION 

E-30  Parameter  'val*  not  0.0  to  1.0  Return 

ALSO  SEE: 

scale 
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remove 


remove 


NAME: 

remove  * erase  the  indicated  oortlon  of  the  picture 
and  remove  the  associated  element  block 
from  the  display  list 

SYNOPSIS: 

remove (num, "e1el"»"ele2"»,..,»"elel0"); 

Int  num:  PIC  / 00  all  elements 

1 • 10  soecifled  elements 

To  remove  the  entire  picture: 

removelPIC ) ; 

To  remove  element  structures: 

remove (num » "elel"»"ele2"»..); 

DESCRIPTION: 

The  entire  picture*  or  every  occurrence  of  the  named 
elements  are  erased  from  the  vector  general  display 
screen.  Each  named  element  structure  will  be  removed 
from  the  display  list.  The  routine  removes  all  occu- 
rances  of  the  specified  elements  Including  elements 
constructed  with  the  copyeleO  routine. 

To  redisplay  any  portion  of  the  removed  picture  re- 
quires that  the  user  rebuild  each  element  and  relink 
It  to  the  appropriate  objects. 

The  parameter  'num*  specifies  the  number  of  element 
names  being  passed  In  this  routine  and  may  vary  from  1 
to  10. 

DIAGNOSTICS: 

All  errors  will  be  printed  on  the  PDP-11  terminal 
screen. 

ERROR  CAUSE  ACTION 

E-6  Specified  element  does  not  Skip 

eilst  element 

E-18  Parameter  *num'  not  1 to  10  num  s 10 


also  SEE: 


I 


rotate 


rotate 


NAME: 


rotate  - rotate  an  object 


SYNOPSIS: 

rot  ate ( "ob i name” / X radi ans# yradi ans  (#zradians]  ); 
float  xradiansrvradianSfZradians: 


description: 

The  named  object  will  be  rotated  about  the  xr  v»  z 
coordinate  axis.  The  oarameters*  given  In  radian  meas* 
ure*  specify  the  degree  of  rotation  desired  about  each 
axis. 

The  z parameter  is  reaulred  only  Mhen  the  coordinate 
system  is  defined  as  three  dimensional  and  will  be 
ignored  otherwise. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  PDP-11  terminal 
sc  reen . 

ERROR  CAUSE  ACTION 

E-5  Specified  objname  does  not  Return 

ex  i St 


i 
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1 


I 

s 


seal  • 


scale 


NAME: 


scale  * modify  object  scale 


SYNOPSIS: 

seal e ( "ob j name" » scale); 
float  scale:  0.0  to  1.0 


DESCRIPTION: 

All  elements  associated  with  the  named  object  are 
scaled  by  the  value  scale  at  display  time.  The  range 
of  scale  is  from  zero  to  one.  Normal  or  default  ob- 
ject scaling  corresponds  to  seal e ( "ob j name" » 1 .0 ) . 


DIAGNOSTICS: 


A1 1 errors  will  be 

printed  on  the 

POP-11  terminal 

screen . 

ERROR 

CAUSE 

ACTION 

E-5 

Speci f i ed 

Ob j name  does  not 

Return 

E-30 

ex  i St 
Parameter 

'scale*  not  0.0  to 

1.0  Return 

ALSO  SEE: 


pscale 


s«t vector 


set  vector 


NAME: 


setvector  - specify  the  vector  type  and  vector  mode 


SYNOPSIS: 


setvector (vtvoe» vmode  l» incl  I»scal el  ); 


int  vtype: 

VR 

VRX 

VRY 

VR2 

VA 

VAX 

VAY 

VAZ 

INC2 

INCX 

INCY 

INC3 


vector  relative 

vector  relative  auto-increment  x 
vector  relative  auto-increment  y 
vector  relative  auto-increment  2 
vector  absolute 

vector  absolute  auto-increment  x 
vector  absolute  auto-increment  y 
vector  absolute  auto-increment  z 
vector  incremental  2-dimensional 
vector  incremental  auto-increment 
vector  incremental  auto-increment 
vector  incremental  3-dimensional 


int  vmode: 

LN 


DSH  / 020  - 
DOT  / OttO  - 
PNT  / 060  - 
DO  /0120  - 
ODD  /01«0  - 


I f ne 

dashed  1 i ne 
dotted  1 i ne 
end  point 

dash-dot -dash  line 
dash-dot -dash  line 


float  scale: 

MG  / 120.0 


NMG  / 0.0 


add  the  coordinate  increments 
to  the  high  order  bits  of  the 
specified  register, 
add  the  coordinate  increments 
to  the  low  order  bits  of  the 
specified  register. 


float  inc: 


DESCRIPTION: 


This  routine  specifies  which  one  of  the  12  vector 
types  is  to  be  drawn  in  the  line^  move/  circle  and  arc 
instructions  which  follow.  It  also  specifies  the  vec- 
tor mode  (i.e./  line/  dotted/  dashed#  etc.)#  and  if 
reguired#  the  increment  value  for  auto-increment  vec- 
tors and  the  scale  factor  for  incremental  vectors. 
The  coordinate  values  passed  in  the  following  draw 
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r 


set  vector 


set  vector 


Instructions  are  deoendent  on  the  vector  type  selected 
in  this  routine. 

This  must  follow  a draweleO  call  and  proceed  any  draw 
instructions.  This  routine  can  be  called  any  number  of 
times  within  a draw  element  block. 

The  bracketed  z parameters  are  required  only  when  the 
coordinate  system  has  been  defined  as  three  dimension- 
al . 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the 

POP-ll  terminal 

screen. 

ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return 

E-a 

No  space  available  in 
display  list 

Return 

E-IO 

Improper  vector  mode 

vmode  * 

LN 

E-ia 

Improper  vector  type 

vtype  = 

VA 

E-15 

Specified  xinc  out-of-bounds 

xinc  • 

xm  i n 

or 

xmax 

or 

0.0 

E-16 

Specified  yinc  out-of-bounds 

yinc  s 

ymi  n 

or 

ymax 

or 

0.0 

E-17 

Specified  zinc  out-of-bounds 

zinc  s 

zmi  n 

or  zmax 
or  0.0 


I 


••tvcetor  - VA 


setvector  - VA 


NAME: 

VA  - vector  absolute 

SYNOPSIS: 

dr awe  1 e ( "el ename" ) » 


setvector (VAfvmode) t 
moveCcoordx rcoordv  (»coordz1  ); 

Hne(coorax  rcoordv  I»coordzl  ); 

cl rcle(di r*centx*centv  t»centz)  )» 

arc (dl r, cent  * fCent y I » cent zl » endx » endy  t»endzJ  )* 


endel e( ) ? 

float  coordx»coordy f coordz; 

float  centxfcenty«centzrendx»endy»endz: 


DESCRIPTION: 

The  x^y^z  coordinates  of  absolute  vectors  are  sped* 
fled  with  respect  to  the  origin#  or  zero  position  of 
the  user  defined  coordinate  system.  Each  x#  y#  z coor- 
dinate value  references  a unique  point  on  the  display 
screen.  Under  this  vector  type#  coordinate  parameters 
for  move/ 1 1 ne/arc/c I rc I e commands  which  fall  outside 
the  defined  coordinate  system  will  assume  a value  of 
the  nearest  coordinate  within  the  defined  system. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP-11  terminal 

screen. 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return 

E-2 

No  space  available  In 
display  II  St 

Return 

E-10 

Improper  vector  mode 

vmode  3 

LN 

E-14 

Improper  vector  type 

vtype  = 

VA 
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s«tvector 


VAX 


setvector  - VAX 


w 

NAME: 

VAX  - vector  absolute  auto-i ncrement  * 

SYNOPSIS: 

drawele("elenaine")» 


setvectorCVAXr  vmode«  x i nc  ) : 
mowe(coordv  (»cooPdzl  )» 

Mne(coordy  (»cooPdzJ  )» 

ci rc1e(di p»centy  [»centzl  )»  ' 

arc (di r,centy  t»centz) »endy  l»endzl  )» 

. I 

endeleO;  ' 

float  X i nc rcoordy r coordz » 
float  cent y » cent z » endy » endz : 


» 


i 


\ 

i 


description: 

The  vector  absolute  auto"i ncrement  x causes  the  ini- 
tial X coordinate  value  to  be  incremented  or  decre- 
mented by  the  value  soecified  by  * x i nc  ' . With  every 
move/ I i ne/arc/c i rc I e command  the  specified  v and  z 
coordinate  values  are  updated  while  the  x coordinate  ^ 

value  is  incremented  by  the  constant  value  'xinc'. 

For  example#  the  point  (x#y#z)  becomes  point  (x+xinc# 
coordy#coordz) . Under  this  vector  type#  coordinate 
parameters  for  move/ I i ne/arc/c i rc I e commands  which 
fall  outside  the  defined  coordinate  system  will  assume 
a value  of  the  nearest  coordinate  within  the  defined 
system. 

A 'xinc*  parameter  exceeding  one-half  the  coordinate 
range  will  be  set  to  zero. 


DIAGNOSTICS: 


All  errors  will 

be  printed  on  the 

PDP-11  terminal 

screen. 

ERROR 

CAUSE 

ACTION 

E-1 

Rout i ne 

has  been  called 

Return 

outside 

a draweleO  block 

E-2 

No  space 

' avai 1 abl e in 

Return 

di  sol  ey 

list 
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setvector  - VAX 


setvector  -VAX 


e-io 

Imppooer  vector  mode 

vmode  • LN 

E-14 

Imppooer  vector  type 

vtype  - VA 

E-15 

Specified  'xinc*  out-of-bounds 

xinc  = 0.0 

i 
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s«t vector 


VAY 


set  vector 


VAY 


r 

NAME: 

VAY  - vector  absolute  auto-increment  v 


SYNOPSIS: 

drawe1e("e1 ename" ) ; 


setvectorlVAYfvmoderyinc): 
movelcoordx  (/coordz)  )/ 

Hne(coordx  (>coordtl  )» 

c i rc 1 e (di recent  X [»centzl  ); 

arc (di r rcent X [ / cent z] » endx  l>endz}  )» 


ende 1 e ( ) : 

float  vinc/Coordx»coordz; 
float  cent  X fcent z > endx > endz ; 


DESCRIPTION: 

The  vector  absolute  auto-increment  y causes  the  ini- 
tial y coordinate  value  to  be  incremented  or  decre- 
mented by  the  value  soecified  by  'yinc*.  with  every 
move/ 1 i ne/arc/c i rc 1 e command  the  specified  x and  z 
coordinate  values  are  updated  Mhile  the  y coordinate 
value  is  incremented  by  the  constant  value  *yinc'. 
For  example^  the  point  (x/V/z)  becomes  the  point 
(coordx » y ty i nc »coordz ) . Under  this  vector  tyoe»  coor- 
dinate parameters  for  move/ 1 i ne/arc/c i rc 1 e commands 
Mhich  fall  outside  the  defined  coordinate  system  will 
assume  a value  of  the  nearest  coordinate  within  the 
defined  system. 

A 'yinc'  parameter  exceeding  one-half  the  coordinate 
range  will  be  set  to  zero. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the 

screen. 


f 

$ 


ERROR 

E-l 

E-2 


CAUSE 

Routine  has  been  called 
outside  a draweleO  block 
No  space  available  in 
display  list 
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POP-1 1 termi nal 

ACTION 

Return 


i 


Return 


’ 

setvector  - 

VAY 

setvectop  - VAY 

E-10 

• Imppooep  vectop 

mode 

vmode  = LN 

E-ia 

Imppopep  vectop 

type 

vtype  ~ VA 

E-16 

Specified  'vine* 

out-of-bounds 

vine  = 0,0 

i 


setvector  - VAZ 


setvector  - VAZ 


NAME: 


VAZ  - vector  absolute  auto-increment  z 

SYNOPSIS: 

drawel e("elename")» 


setvector(VAZf  vmode^  z i nc ) ; 
move (coord X » coo rdy ) ; 
line(coordx»coordy)? 
circle(dir,centx,centy); 
arcCdi rfcentx»centyfendx«endy); 


endel eC ) » 

float  z i nc r coordx » coordy ; 
float  centx^centy »endx,endy; 


DESCRIPTION: 


The  vector  absolute  auto-increment  z causes  the  ini- 
tial z coordinate  value  to  be  incremented  or  decre- 
mented by  the  value  specified  by  'zinc*,  with  every 
move/line/arc/circle  command  the  specified  x and  y 
coordinate  values  are  updated  while  the  z coordinate 
value  is  incremented  by  the  constant  value  'zinc'. 
For  example/  the  point  (x/y/z)  becomes  the  point 
(coordx » coory » z + z i nc  ) . Under  this  vector  type/  coor- 
dinate parameters  for  move/ 1 i ne/arc/c i rc 1 e commands 
which  fall  outside  the  defined  coordinate  system  will 
assume  a value  of  the  nearest  coordinate  within  the 
defined  system, 

A 'zinc'  parameter  exceeding  one-half  the  coordinate 
range  will  be  set  to  zero. 


DIAGNOSTICS: 

All  errors  will  be  printed  on  the  PDP-11  terminal 

screen. 


ERROR  CAUSE 

E-1  Routine  has  been  called 

outside  a draweleO  block 
E-2  No  space  available  in 

display  1 i st 


ACTION 

Return 

Return 
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setvector  - VAZ  , setvector  - VAZ 

1*^  ; 

E-10  Imoroper  v«ctor  mode  vmode  = LN 

I E“l<»  Improper  vector  type  vtvpe  = VA 

E-17  Specified  'zinc'  out-of-bounds  zinc  - 0,0 


setvector  - VR 


setvector  - VR 


NAME;  VR  - vector  relative 

SYNOPSIS: 

dr awe  1 e("elename"); 


setvector(VR»vmode); 
move(del tax>del tav  (rdeltazl  ); 

HneCde?  taxf  del  tay  {»deltazl  ); 

ci rcle(di r,centx»centy  (»centz]  )» 

arc (di r/centx»centy  [#centz] »endx/endy  [/endzl  ); 


endel e ( ) > 

float  del taxfOel tay# del taz: 

float  centx»centy»centz»endxfendyrendz; 


DESCRIPTION! 

Relative  vectors  specify  an  increment  value  that  is  to 
be  added  to  or  subtracted  from  the  initial  XfVrZ  beam 
position.  For  example*  the  point  (x*y*z)  becomes 
point  (xfdel tax/yfdel tay/z+del taz). 

Under  this  vector  type*  coordinate  parameters  for 
move/ 1 i ne/arc/c i rc  I e commands  which  exceed  one^half 
the  coordinate  range  will  be  set  to  zero. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP-11  terminal 
screen. 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
within  a draweleO  block 

Return 

ru 

1 

UJ 

No  apace  available  in 
display  list 

Return 

E-10 

Improper  vector  mode 

vmode  = 

LN 

E-ia 

Improper  vector  type 

vtype  = 

VA 

sctvector  - VHX 


setvector  - VRX 


NAME: 

VRX  - vector  relative  autO"increment  x 


SYNOPSIS: 

dr awe ) e ( "e 1 ename" ) ! 


setvector(VRX»vmode»xinc) 
move(de1tay  (>de1taz]  ): 

1ine(de1tay  (#de1tazl  ): 

ci rc 1 e(di r »centy  (>centz]  ); 

arc (di r»centy  t»centzl »endy  (#endz]  ); 


ende 1 e ( ) : 

float  »inc#de1 tay«del taz; 
float  centy»centz»endy»endz; 


DESCRIPTION: 

A vector  relative  auto-increment  x causes  the  initial 
X coordinate  value  to  be  incremented  or  decremented  by 
the  constant  value  'xinc'.  With  every  move/ 1 i ne/arc/ 
circle  instruction  that  followsr  the  y and  z coordi- 
nate values  will  be  uodated^  while  x is  stepped  by  the 
value  'xinc'*  For  example#  the  point  (x#y#z)  becomes 
the  point  ( x + x i nc # y ♦de 1 1 ay # ztdel t az ) . 

Under  this  vector  type#  coordinate  parameters  for 
move/ 1 i ne/arc /c i rc I e commands  which  exceed  one-half 
the  coordinate  range  will  be  set  to  zero. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  POP-11  terminal 
screen. 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a drawele()  block 

Return 

E-2 

No  space  available  in 
display  list 

Return 

E-10 

Improper  vector  mode 

vmode  * LN 

E-ia 

Improper  vector  type 

vtype  = VA 

E-15 

Soecified  'xinc'  out-of-bounds 

xinc  • 0.0 
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setvector  - VRY 


setvector  - VRY 


NAME: 


VRY  - vector  relative  auto-i ncrement  y 
SYNOPSIS: 

drawe1e("e1 ename" ) » 


setvector  (VRY  ^.vinode*  y i nc  ) 

<nove(de1  tax  l»de1tazl  )> 

1ine(de1tax  («de1taz)  ); 

ci rc1e(di r»centx  I/centzl  ); 

arc (di rr cent  X (rcentzl »endx  Crendzl  )! 


endei e( ) ; 

float  yinCfdel tax/del taz; 
float  cent X »cent z f endx f endz r 


description: 

A vector  relative  auto-increment  y causes  the  initial 
y coordinate  value  to  be  incremented  or  decremented  by 
the  constant  value  'yinc'»  With  every  move/ I i ne/arc/ 
circle  instruction  that  follows#  the  x and  z coordi- 
nate values  will  be  updated#  while  y is  incremented  by 
the  value  'vine'*  For  example#  the  point  (x#y#z) 
becomes  the  point  ( x tdel t ax # y+y i nc # z+del t az ) . 

Under  this  vector  type#  coordinate  parameters  for 
move/ I i ne/arc/c i rc I e commands  which  exceed  one-half 
the  coordinate  range  will  be  set  to  zero. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the 
screen . 

POP-ll  terminal 

ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return 

m 

1 

UJ 

No  space  available  in 
display  list 

Return 

E-10 

Improper  vector  mode 

vmode  3 ln 

E-IS 

Improper  vector  type 

vtype  s VA 

E-16 

Specified  'yinc*  out-of-bounds 

yinc  » 0,0 
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setvector  - VRZ 


setvector  - VRZ 


i 


I 


■r 

•r 

NAME:  : 

VRZ  - vector  relative  auto-increment  z 


SYNOPSIS: 

dr awe 1e("elename")» 


set  vector (VRZ » vmode#  zinc) 
move(de1tax#de1tay)) 

1 ine(de1 taxydel tav) ; 
circie(dir»centa»centy); 
arc(dir«centx>centy»endx  r endy ) » 


ende)e( ) ; 

float  zinCfdel taxfdel tay; 
float  centx»centy»endx»endy; 


DESCRIPTION: 


A vector  relative  auto-increment  z causes  the  initial 
z coordinate  value  to  be  incremented  or  decremented  by 
the  constant  value  'zinc',  with  every  move/ 1 i ne/arc/ 
circle  instruction  that  follows,  the  x and  y coordi- 
nate values  will  be  uodated.  while  z is  incremented  by 
the  value  'zinc'.  For  example.  the  point  (x.y.z) 
becomes  the  point  (xtdel  tax.ytdel  tay.Z't’incz) . 

Under  this  vector  type.  coordinate  parameters  for 
move/ 1 i ne/arc/c i rc 1 e commands  which  exceed  ' one-half 
the  coordinate  range  will  be  set  to  zero. 


DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP-11  terminal 

screen. 


ERROR  CAUSE 

E-1  Routine  has  been  called 

outside  a draweleO  block 
E-?  No  space  available  in 

display  list 

E-10  Improper  vector  mode 

E-l<t  Improper  vector  type 

E-17  Specified  'zinc'  out-of-bounds 


ACTION 

Return 

Return 

vmode  a LN 
vtype  * VA 
zinc  s 0.0 


isa 


• IMJI 


setvector  - INC2 


set  vector 


INC2 


NAME: 

INC2  - Incremental  vector;  two-dimensional 


SYNOPSIS: 

dr awe  1 e ( "el ename" ) ! 


setvector(INC2«vmodef scale) ; 
moveCdeltaxydeltav); 

I ine(del tax^del tay) ; 


endel e ( ) ; 

float  del tax/Oel tay ; 
float  scale: 

MG  / 120.0  - add  the  coordinate  increments  to 

the  7 high  order  bits  of  the 
specified  register. 

NMG  / 0.0  • add  the  coordinate  increments  to 

the  7 low  order  bits  of  the 
soecified  register. 


DESCRIPTION: 

A two-dimensional  relative  vector  that  halves  vector 
storage  requirements  and  doubles  the  data  rate.  This 
vector  tyoe  should  be  used  when  element  storage  space 
is  critical.  This  reduced  storage  reauirement  results 
from  a limitation  on  the  maximum  size  of  each  relative 
increment.  The  values  passed  in  move/line  instructipns 
are  limited  to  approximately  3X  of  the  user  minimum 
and  maximum  coordinate  ranges.  Should  coordinate 
parameters  for  move/line  commands  exceed  the  iX  limit* 
they  will  be  reduced  to  satisfy  the  constraint. 

The  parameter  'scale*  specifies  whether  this  increment 
value  should  be  added  to  the  7 high  order  bits  of  the 
specified  coordinate  or  to  the  7 low  order  bits.  This 
scale  factor  then  determines  if  the  increments  will  be 
applied  over  a fine(NMG)  or  coarse(MG)  grid. 

Arcs  and  circles  cannot  be  drawn  with  this  vector 


setvector 


INC2 


setvector 


1NC2 


DIAGNOSTICS 


ACTION 

Return 


ERROR 

E-1 


CAUSE 

Routine  has  been  called 
outside  a draweleO  block 
No  space  available  in 
display  I i st 
Improper  vector  type 


vtype 


setvector  - INC3 


setvector  - INC3 


NAME: 


INC3  - incremental  vector?  three-dimensional 

SYNOPSIS: 


drawe1e("el ename" ) » 


setvectordNCX#  vmode»  scale)? 
move(deltaxrdeltayfdeltaz)? 

1 ine(delta»fdeltay>deltaz)? 


ende 1 e ( ) ? 

float  del  tax >del tay f del taz? 
float  scale: 

MG  f 120.0  - add  the  coordinate  increments  to 

the  7 high  order  bits  of  the 
soec i f i ed  register. 

NMG  / 0.0  - add  the  coordinate  increments  to 

the  7 low  order  bits  of  the 
soecified  register. 


DESCRIPTION: 

A three-dimensional  relative  vector  that  halves  vector 
storage  requirements  and  doubles  the  data  rate.  This 
vector  type  should  be  used  when  element  storage  space 
is  critical.  This  reduced  storage  requirement  results 
from  a limitation  on  the  maximum  size  of  each  relative 
increment.  The  values  Passed  in  move/line  instructions 
are  limited  to  aoprox i matel y 3%  of  the  user  minimum 
and  maximum  coordinate  ranges.  Should  coordinate 
parameters  for  move/line  commands  exceed  the  3X  limits 
they  will  be  reduced  to  satisfy  the  constraint. 

Tr.e  parameter  'scale'  specifies  whether  this  increment 
value  should  be  added  to  the  7 high  order  bits  of  the 
specified  coordinate  or  to  the  7 low  order  bits.  This 
scale  factor  then  determines  if  the  increments  will  be 
applied  over  a fine(NMG)  or  coarse(MG)  grid. 

Arcs  and  circles  cannot  be  drawn  with  this  vector 
type. 
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setvector  - INC3 


setvector  - INC3 


i 

■ 

i 

1*1  ! 

DIAGNOSTICS: 


All  errors  will  be  printed  on  the  P0P«11  terminal 
screen. 


ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return  i 

E-2 

No  space  available  in 

Return  ? 

display  list 

< 

E-ltt 

Improper  vector  type 

vtype  ~ VA  j 

setvector  - INCX 


setvector  - INCX 


NAME: 


INCX  • incremental  vector;  two-dimensional 
auto-increment  x 


SYNOPSIS: 


drawe1e("elename"); 


setvectordNCXfvmode/xinoscale); 

moveldeltavfdeltay); 

1 i ne(del tay »del tay) ; 


ende i e () » 

float  xinCfdeltay; 
float  scale: 

MG  / 128.0  - add  the  coordinate  increments  to 

the  7 high  order  bits  of  the 
soecified  register. 

NMG  / 0.0  - add  the  coordinate  increments  to 

the  7 low  order  bits  of  the 
soecified  register. 


DESCRIPTION: 

A two-dimensional  relative  vector  that  halves  vector 
storage  requirements  and  doubles  the  data  rate.  This 
vector  tyoe  should  be  used  when  element  storage  space 
is  critical.  This  reduced  storage  requirement  results 
from  a limitation  on  the  maximum  size  of  each  relative 
increment.  The  values  passed  in  move/line  instructions 
are  limited  to  approximately  3X  of  the  user  minimum 
and  maximum  coordinate  ranges.  Should  the  coordinate 
parameters  for  movc/Hne  commands  exceed  the  3Z  limit# 
they  will  be  reduced  to  satisfy  the  constraint. 

The  parameter  'scale*  specifies  whether  this  increment 
value  should  be  added  to  the  7 high  order  pits  of  the 
specified  coordinate  or  to  the  7 low  order  bits*  This 
scale  factor  then  determines  if  the  increments  will  be 
applied  over  a fine(NMG)  or  coarse(MG)  grid. 

This  incremental#  auto-increment  vector  causes  the  x 
coordinate  value  to  be  incremented  or  decremented  by 
the  constant  value  'xinc'#  while  the  y coordinate 
value  is  increment  by  small  relative  values.  The 
'xinc*  value  need  not  be  limited  to  IX  of  the 


set  vector 


INCX 


set  vector 


INCX 


coordinate  range  but  may  not  exceed  one-half  the  coor- 
dinate range  or  it  will  be  set  to  zero* 

Arcs  and  circles  cannot  be  drawn  with  this  vector 
type. 

DIAGNOSTICS: 


All  errors  will  be  printed  on  the  PDP- 
screen. 

11  terminal 

ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a drawele()  block 

Return 

E-2 

No  space  available  in 
display  list 

Return 

E-ia 

Improper  vector  tyoe 

vtype  = VA 

E-15 

Specified  'xinc*  out-of-bounds 

xinc  - 0,0 

setvector  - INCY 


setvectop  - INCY 


I 


NAME: 


INCY  - incremental  vector;  t MO~di mens i ona 1 
auto-i ncrement  v 


SYNOPSIS; 

drawe1e("e1 ename" ) ; 


setvector(INCY,vmode»yinc»sca1e)? 
move(de1 taxrdeltax); 

I ineCdeftax^deltax); 


ende 1 e ( ) ; 

float  y i nc » del t ax ; 
float  scale: 

MG  / 128.0  - add  the  coordinate  increments  to 

the  7 high  order  bits  of  the 
soecified  register. 

NMG  / 0.0  - add  the  coordinate  increments  to 

the  7 low  order  bits  of  the 
specified  register. 


f 


-JL 


DESCRIPTION: 

A two'dimensional  relative  vector  that  halves  vector 
storage  requirements  and  doubles  the  data  rate.  This 
vector  type  should  be  used  when  element  storage  space 
is  critical.  This  reduced  storage  requirement  results 
from  a limitation  on  the  maximum  site  of  each  relative 
increment.  The  values  passed  in  move/line  instructions 
are  limited  to  approximately  iX  of  the  user  minimum 
and  maximum  coordinate  ranges.  Should  the  coordinate 
parameters  of  move/line  commands  exceed  the  3%  limit, 
they  will  be  reduced  to  satisfy  the  constraint. 

The  parameter  'scale*  specifies  whether  this  increment 
value  should  be  added  to  the  7 high  order  bits  of  the 
soecified  coordinate  or  to  the  7 low  order  bits. 
This  scale  factor  then  determines  if  the  increments 
will  be  applied  over  a fine(NMG)  or  coarse(MG)  grid. 

This  incremental,  auto-increment  vector  causes  the  y 
coordinate  value  to  be  incremented  or  decremented  by 
the  constant  value  'yinc'.  while  the  x coordinate 
value  is  increment  by  small  relative  values.  The 
•yinc'  value  need  not  be  limited  to  3X  of  the 


i 

\ 
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f 


1 

i 


s«tv«ctor  « INCY  satvector  - INCY 


coordinate  range  but  may  not  exceed  one*ba1f  the  coor- 
dinate range  or  it  will  be  set  to  zero* 

Arcs  and  circles  cannot  De  drawn  with  this  vector 
type. 


DIAGNOSTICS: 


AJl  errors  will  be  printed  on  the  POP- 
screen . 

11  terminal 

ERROR 

CAUSE 

ACTION 

E-1 

Routine  has  been  called 
outside  a draweleO  block 

Return 

E-2 

No  space  available  in 
display  list 

Return 

E-ia 

Improper  vector  type 

vtype  = VA 

E-16 

Specified  'yinc*  out-of-bounds 

yinc  = 0,0 

I 

i 

i 

a 

i 

i 

I 


J 


\ 

1 

i 

I 


IjPilJJU 


SYNOPSIS 


DESCRIPTION 


All  of  the  elements  associated  with 
are  translated  from  their  present  loc 
(Xtdel t a*»  Ytde 1 tav»  Ztdel tar) . 


eter  is  reouired  only  when  the 
defined  as  three  dimensional r 
included  under  a two*dimensional 


DIAGNOSTICS 


CAUSE 

Specified  object  does  not 
es  i St 

Specified  deltas  out*of “bounds 
Specified  deltay  out*of -bounds 
Specified  del  tar  out-of-bounds 


ERROR 

E-5 


vgoleturt 


vgpfcture 


NAME: 


vgpicture  * start  refresh  of  VG  picture  display 


SYNOPSIS: 


vgp1cture( ) ; 


DESCRIPTION: 


This  routine  must  be  called  to  Initiate  the  display  of 
elements  on  the  VG  display  screen.  The  routine  need 
be  called  only  once.  The  dIsplayO  routine  may  be 
called  after  this  routine  to  activate  or  deactivate 
the  display  of  all  or  parts  of  the  display  picture. 


DIAGNOSTICS: 


ALSO  SEE: 


display^  eraser  remove 


s 


vgterm 


vgt«riii 


vgterm  « terminate  display  and  close  VG  device 


SYNOPSIS: 

vgterm( ) ; 


DESCRIPTION: 

This  routine  should  be  Included  at  the  end  of  the 
user's  program  to  properly  terminate  the  display  and 
close  the  VG  device.  Should  the  user's  program  con* 
tain  an  endless  loop#  depressing  the  'rubout'  key  will 
accomplish  the  same  task. 


DIAGNOSTICS: 

none 
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